You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I compiled GDAL 3.8.5 with support for the PGeo driver on an M1 MacOS, but when I ran the command ogrinfo --debug on -if PGeo 640122HLX_2006Y00_SV050_P.mdb, I received the following debug information:
ODBC: Declaration of Microsoft Access Driver found in /etc/odbcinst.ini
ODBC: EstablishSession(DRIVER=Microsoft Access Driver (*.mdb, *.accdb);DBQ=640122HLX_2006Y00_SV050_P.mdb)
ODBC: SQLDriverConnect(DRIVER=Microsoft Access Driver (*.mdb, *.accdb);DBQ=640122HLX_2006Y00_SV050_P.mdb)
ODBC: ... failed:
ODBC: SQLDisconnect()
ODBC: EstablishSession(DRIVER=Microsoft Access Driver (*.mdb, *.accdb);DBQ="640122HLX_2006Y00_SV050_P.mdb")
ODBC: SQLDriverConnect(DRIVER=Microsoft Access Driver (*.mdb, *.accdb);DBQ="640122HLX_2006Y00_SV050_P.mdb")
ODBC: ... failed:
ODBC: SQLDisconnect()
ODBC: EstablishSession(DRIVER=Microsoft Access Driver (*.mdb);DBQ=640122HLX_2006Y00_SV050_P.mdb)
ODBC: SQLDriverConnect(DRIVER=Microsoft Access Driver (*.mdb);DBQ=640122HLX_2006Y00_SV050_P.mdb)
PGEO: SELECT on GDB_GeomColumns fails, perhaps not a personal geodatabase?
ODBC: SQLDisconnect()
Additionally, the program becomes unresponsive and cannot be stopped, while consuming 100% CPU on a single core (possibly due to an infinite loop?).
One particularly valuable piece of information was: 'PGEO: SELECT on GDB_GeomColumns fails, perhaps not a personal geodatabase?'
I attempted to trace the GDAL source code and by adding debug information, it seems that the issue occurs when executing the following SQL statement:
// /ogr/ogrsf_frmts/pgeo/ogrpgeodatasource.cpp
std::vector<char **> apapszGeomColumns;
CPLODBCStatement oStmt(&oSession);
oStmt.Append(
"SELECT TableName, FieldName, ShapeType, ExtentLeft, ExtentRight, ""ExtentBottom, ExtentTop, SRID, HasZ, HasM FROM GDB_GeomColumns");
if (!oStmt.ExecuteSQL())
{
CPLDebug("PGEO",
"SELECT on GDB_GeomColumns fails, perhaps not a personal ""geodatabase?\n%s",
oSession.GetLastError());
returnFALSE;
}
Continuing the trace, it appears that the SQLExecDirect method returns -2, but no valuable error information is captured.
As I am not very familiar with C++, I am unable to further trace the issue. It is clear, however, that the SQLExecDirect method is from unixODBC (if I understand correctly).
// /port/cpl_odbc.cpp// SQL_NTS=-3 is a valid value for SQLExecDirect.// coverity[negative_returns]if (Failed(SQLExecDirect(
m_hStmt, reinterpret_cast<SQLCHAR *>(m_pszStatement), SQL_NTS)))
returnFALSE;
return CollectResultsInfo();
Furthermore, I tried executing the problematic SQL statement directly through unixODBC and encountered no issues. I configured the mdb file in odbc.ini and used the isql command to read it as follows:
I am confident that there is no issue with the mdb file itself, as I not only compiled GDAL on my machine but also added the PGeo driver to the official ARM version of the GDAL Docker image. I then executed the same command against the same mdb file within the container and obtained the correct results. The output was as follows:
Install unixODBC, mdbtools, etc., compile GDAL 3.8.5, and execute the command: ogrinfo --debug on -if PGeo xxx.mdb. The compilation command is as follows:
as I not only compiled GDAL on my machine but also added the PGeo driver to the official ARM version of the GDAL Docker image
which docker image exactly? We have 4 variants. So this does work on Arm with a GDAL Docker image, but not in your native environment? Personally, I won't be able to investigate now owing a Mac
as I not only compiled GDAL on my machine but also added the PGeo driver to the official ARM version of the GDAL Docker image
which docker image exactly? We have 4 variants. So this does work on Arm with a GDAL Docker image, but not in your native environment? Personally, I won't be able to investigate now owing a Mac
Yes, it runs normally in the ARM-based Docker image container, which is also running on Docker on my Mac, but there are issues in my local MacOS ARM environment. I am using this image: https://github.com/OSGeo/gdal/pkgs/container/gdal/180417381?tag=ubuntu-full-3.8.4
I noticed one difference: in the image, the unixODBC version is 2.3.9.
What is the bug?
I compiled GDAL 3.8.5 with support for the
PGeo
driver on anM1 MacOS
, but when I ran the commandogrinfo --debug on -if PGeo 640122HLX_2006Y00_SV050_P.mdb
, I received the following debug information:Additionally, the program becomes unresponsive and cannot be stopped, while consuming 100% CPU on a single core (possibly due to an infinite loop?).
One particularly valuable piece of information was:
'PGEO: SELECT on GDB_GeomColumns fails, perhaps not a personal geodatabase?'
I attempted to trace the GDAL source code and by adding debug information, it seems that the issue occurs when executing the following SQL statement:
Continuing the trace, it appears that the
SQLExecDirect
method returns-2
, but no valuable error information is captured.As I am not very familiar with C++, I am unable to further trace the issue. It is clear, however, that the
SQLExecDirect
method is fromunixODBC
(if I understand correctly).Furthermore, I tried executing the problematic SQL statement directly through
unixODBC
and encountered no issues. I configured the mdb file inodbc.ini
and used theisql
command to read it as follows:I am confident that there is no issue with the mdb file itself, as I not only compiled GDAL on my machine but also added the
PGeo
driver to the official ARM version of theGDAL Docker image
. I then executed the same command against the same mdb file within the container and obtained the correct results. The output was as follows:Steps to reproduce the issue
Install unixODBC, mdbtools, etc., compile GDAL 3.8.5, and execute the command: ogrinfo --debug on -if PGeo xxx.mdb. The compilation command is as follows:
Versions and provenance
M1 pro MacOS 14.4.1
Additional context
No response
The text was updated successfully, but these errors were encountered: