Segfaults with recent builds of mod_spatialite

139 views
Skip to first unread message

Brice Lambson

unread,
Aug 20, 2019, 2:39:01 PM8/20/19
to SpatiaLite Users
We recently started seeing segfaults when trying to "SELECT load_extension('mod_spatialite');" on recent versions. I think it's caused by PROJ being linked against libspatialite3-0. This cripples SQLite extensions since the native library name can change (e.g. libsqlcipher). Is this a know issue?

a.fu...@lqt.it

unread,
Sep 2, 2019, 12:52:57 PM9/2/19
to spatiali...@googlegroups.com
Hi Brice,

mod_spatialite is a rather complex sw component, and not at all
surprisingly it has an unusually elevated number of dependencies,
that in turn may require further dependencies.

this is the situation for the current development version; all
the following dependencies are required: freexl, libgeos_c,
libgeos, libproj, librttopo, libxml2, liblzma and obviously
libsqlite3 itself (and may well be some else more on specific
platforms such as Windows).

each one of these dependencies may easily cause a crash (segfault)
if it's not of the expected version thus presenting some API/ABI
incompatibility. in other words: mixing at random libraries of
different origin/generation is a well known recipe leading to
disaster.

you are saying absolutely nothing about your operating system and
about the versions of all libraries you are using at run-time, and
more in general about your environment (using system packages ?
or using custom built components ?) so it's impossible to guess at
blind the cause of your problems.

I can only ensure you that the most recent versions of mod_spatialite
can surely work in the most pleasant way if they effectively load at
run-time the same version of each depending library being used at
build-time. if such a mandatory prerequisite is not fulfilled
anything can happen, including some unexpected crash.

bye Sandro

Brice Lambson

unread,
Jan 9, 2020, 5:45:38 PM1/9/20
to SpatiaLite Users
I finally got around to debugging this. I was able to confirm my suspicions. Here are the relevant parts of the LD_DEBUG log:

       633:     calling init: /home/bricelam/Test/bin/Debug/netcoreapp3.1/runtimes/linux-x64/native/libe_sqlite3.so
       633:
       633:     calling init: /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
       633:
       633:     calling init: /usr/lib/x86_64-linux-gnu/libproj.so.13
       633:
       633:     calling init: /usr/lib/x86_64-linux-gnu/mod_spatialite.so
       633:
       633:     /usr/lib/x86_64-linux-gnu/mod_spatialite.so: error: symbol lookup error: undefined symbol: sqlite3_extension_init (fatal)

Calling sqlite3_load_extension(db, 'mod_spatialite', ...) from libe_sqlite3 causes libsqlite3 to be loaded as a dependency. Then it tries to call sqlite3_extension_init in mod_spatialite, but it can't reconcile the different versions of SQLite and crashes.

If I take libe_sqlite3 out of the picture and only use libsqlite3, everything works as expected.

Brice Lambson

unread,
Jan 9, 2020, 6:30:31 PM1/9/20
to SpatiaLite Users
Note, this will also affect libraries like SQLCipher that use a different name for their SQLite library.
Reply all
Reply to author
Forward
0 new messages