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 Even Rouault, 11 years ago

Component: defaultOGR_SF
Milestone: 1.10.1

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) ?

Index: ogr/ogrsf_frmts/sqlite/ogrsqlitevirtualogr.cpp
===================================================================
--- ogr/ogrsf_frmts/sqlite/ogrsqlitevirtualogr.cpp	(revision 26306)
+++ ogr/ogrsf_frmts/sqlite/ogrsqlitevirtualogr.cpp	(working copy)
@@ -45,7 +45,7 @@
 #endif
 
 /* Declaration of sqlite3_api structure */
-SQLITE_EXTENSION_INIT1
+static SQLITE_EXTENSION_INIT1
 
 /* The layout of fields is :
    0   : RegularField0
Index: ogr/ogrsf_frmts/sqlite/ogrsqlitevirtualogr.cpp
===================================================================
--- ogr/ogrsf_frmts/sqlite/ogrsqlitevirtualogr.cpp	(revision 26306)
+++ ogr/ogrsf_frmts/sqlite/ogrsqlitevirtualogr.cpp	(working copy)
@@ -2350,7 +2350,10 @@
                                 const sqlite3_api_routines * pApi)
 {
 #ifndef WIN32
-    pApi = &OGRSQLITE_static_routines;
+    if( pApi->create_module == NULL )
+    {
+        pApi = &OGRSQLITE_static_routines;
+    }
 #endif
     SQLITE_EXTENSION_INIT2 (pApi);

comment:2 by Kyle Shannon, 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 Even Rouault, 11 years ago

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.