Opened 11 years ago
Closed 11 years ago
#5195 closed defect (fixed)
OGR sqlite dialect causes a seg fault
Reported by: | Kyle Shannon | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | OGR_SF | Version: | svn-trunk |
Severity: | normal | Keywords: | sqlite dialect |
Cc: |
Description
Using '-dialect sqlite' causes a segfault in ogrinfo:
kyle@kyle-hp-laptop:data$ ogrinfo -sql "select * from us_srtm_region" us_srtm_region.shp -so INFO: Open of `us_srtm_region.shp' using driver `ESRI Shapefile' successful. Layer name: us_srtm_region Geometry: Polygon Feature Count: 1 Extent: (-179.144808, 17.391614) - (179.855192, 60.391614) Layer SRS WKT: GEOGCS["GCS_WGS_1984", DATUM["WGS_1984", SPHEROID["WGS_84",6378137,298.257223563]], PRIMEM["Greenwich",0], UNIT["Degree",0.017453292519943295]] Name: String (80.0) descriptio: String (80.0) timestamp: Date (10.0) begin: Date (10.0) end: Date (10.0) altitudeMo: String (80.0) tessellate: Integer (10.0) extrude: Integer (10.0) visibility: Integer (10.0) drawOrder: Integer (10.0) icon: String (80.0) kyle@kyle-hp-laptop:data$ ogrinfo -sql "select * from us_srtm_region" us_srtm_region.shp -so -dialect sqlite INFO: Open of `us_srtm_region.shp' using driver `ESRI Shapefile' successful. Segmentation fault (core dumped)
Backtrace:
(gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007ffff255d800 in ?? () from /usr/lib/libspatialite.so.3 #2 0x00007fffeed3e8f6 in sqlite3VdbeExec (p=0x63ed88) at sqlite3.c:64826 #3 0x00007fffeed44451 in sqlite3Step (p=0x63ed88) at sqlite3.c:61844 #4 sqlite3_step (pStmt=0x63ed88) at sqlite3.c:61917 #5 sqlite3_step (pStmt=0x63ed88) at sqlite3.c:61905 #6 0x00007fffeed47e4c in sqlite3_exec (db=0x611a18, zSql=0x612018 "SELECT InitSpatialMetadata()", xCallback=<optimized out>, pArg=0x0, pzErrMsg=0x7fffffffda60) at sqlite3.c:89119 #7 0x00007ffff7684508 in OGRSQLiteDataSource::Create (this=0x611820, pszNameIn=0x611710 "/vsimem/ogr2sqlite/reference_0x611710.db", papszOptions=0x6114d0) at ogrsqlitedatasource.cpp:583 #8 0x00007ffff768f0cb in OGRSQLiteExecuteSQL (poDS=0x60f500, pszStatement=0x60f7e0 "select * from us_srtm_region", poSpatialFilter=0x0, pszDialect=0x60fca0 "sqlite") at ogrsqliteexecutesql.cpp:535 #9 0x00007ffff7534471 in OGRDataSource::ExecuteSQL (this=0x60f500, pszStatement=0x60f7e0 "select * from us_srtm_region", poSpatialFilter=0x0, pszDialect=0x60fca0 "sqlite") at ogrdatasource.cpp:1329 #10 0x00007ffff767b5fc in OGRShapeDataSource::ExecuteSQL (this=0x60f500, pszStatement=0x60f7e0 "select * from us_srtm_region", poSpatialFilter=0x0, pszDialect=0x60fca0 "sqlite") at ogrshapedatasource.cpp:928 #11 0x0000000000402d73 in main (nArgc=7, papszArgv=0x60f3d0) at ogrinfo.cpp:249
I stepped through and if I manually call sqlite3_enable_load_extension() and sqlite3_load_extension(), I get through fine. It seems that r26245 may be at fault. I commented out the change and it worked.
Ubuntu 12.04, ubuntu packages for both sqlite and spatialite. My autotests are also segfaulting in the ogr_sql_sqlite.py. I can also load extensions via the sqlite shell and python 3.
Change History (3)
comment:1 by , 11 years ago
Component: | default → OGR_SF |
---|---|
Milestone: | 1.10.1 |
comment:2 by , 11 years ago
Even, both patches seem to allow the tests to pass, independently and together. I'm without a network connection, and there are a lot of http errors, so I will double check in the morning. ogrinfo works fine.
comment:3 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
trunk r26308 "SQLite: fix regression caused by r26245 (trunk only, #5195)"
I've applied boths to limit the scope of the hack introduced by r26245.
The issue was that the "const sqlite3_api_routines *sqlite3_api" behind SQLITE_EXTENSION_INIT1 is something also set in spatialite extension code. But both the GDAL and the spatialite one were global, the one of GDAL contaminated spatialite, but the OGRSQLITE_static_routines table contains only the symbols useful for GDAL, and NULL for the others, thus causing spatialite to crash when it tries to dereference those NULL function pointers.
Hum, what is strange is that the Travis VM is using Ubuntu 12.04 too and it works fine on it. But I admit that r26245 is an awfull trick (that helped on MacOSX default sqlite3 lib that is compiled with SQLITE_OMIT_LOAD_EXTENSION), so I'm not completely surprised of bad effects.
Perhaps could you try to apply one of the 2 following patch on top of trunk (i.e. revert your change first) ?