SpatiaLite 4.1.1 segfault

[linux...@gmail.com]

After libspatialite & spatialite-tools 4.1.1 were rebuild for the libproj 4.9.1 transition in Debian spatialite_init() gets a segfault:

 (gdb) run
 Starting program: /usr/bin/spatialite
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
 
 Program received signal SIGSEGV, Segmentation fault.
 0x00007ffff787fff4 in spatialite_init (verbose=1) at spatialite_init.c:114
 114         sqlite3_auto_extension ((void (*)(void)) init_spatialite_extension);

This issue was reported in Debian Bug #785091 (https://bugs.debian.org/785091).

libspatialite & spatialite-tools 4.2.1-RC1 work as expected, but I'm waiting for the 4.2.1 final release before starting a transition to get them into Debian unstable & testing.

I'm a bit at a loss of what change(s) in 4.2.1 fix the issue. The big difference I found is the use of spatialite_init_ex() in 4.2.1, GDAL uses that too for spatialite >= 4.1.2.

I need to fix the issue in spatialite 4.1.1 to prevent all reverse dependencies of libspatialite (gdal, qgis, etc) from being removed from Debian testing.

Any suggestions where to look for the problematic code, and possible solutions?

Kind Regards,

Bas

[a.fu...@lqt.it]

On Fri, 15 May 2015 04:48:16 -0700 (PDT), linux...@gmail.com wrote:
> After libspatialite & spatialite-tools 4.1.1 were rebuild for the
> libproj 4.9.1 transition in Debian spatialite_init() gets a segfault:
>

> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff787fff4 in spatialite_init (verbose=1) at
> spatialite_init.c:114
> 114 sqlite3_auto_extension ((void (*)(void))
> init_spatialite_extension);
>

Hi Bas,

that's not too much surprising: spatialite_init() is now
deprecated because this method was intrinsically not
reentrant and thus not thread safe.

> I'm a bit at a loss of what change(s) in 4.2.1 fix the issue. The big
> difference I found is the use of spatialite_init_ex() in 4.2.1, GDAL
> uses that too for spatialite >= 4.1.2.
>

spatialite_init_ex() is a full replacement for spatialite_init();
the main difference is in that the new method is thread safe and
effectively supports the more recent thread-safe APIs available
on both GEOS and PROJ.4

> I need to fix the issue in spatialite 4.1.1 to prevent all reverse
> dependencies of libspatialite (gdal, qgis, etc) from being removed
> from Debian testing.
>
> Any suggestions where to look for the problematic code, and possible
> solutions?
>

Please see the attached patch; it's simply intended to support
spatialite_init_ex() on the old 4.1.1 shell.c
I've tested it on Jessie 686-PAE using proj-4.9.1 and it seems
to resolve any issue; Valgrind confirms an absolutely clean run.

bye Sandro

[Bas Couwenberg]

Hi Sandro,

Thanks for the patch, it resolves the issue for the spatialite
executable on unstable too.

It does not fix the issue for gdal, the ogr2ogr command mentioned in
the Debian Bug still causes a segfault.

GDAL 1.10.1 doesn't support spatialite_init_ex() yet, that was added
in 1.11.x. Hopefully I can restart the GDAL transition in Debian soon
to get improvements like these available in testing/unstable.

I've not tested QGIS yet, but since it doesn't support
spatialite_init_ex() at all, it will most likely segfault too.

Kind Regards,

Bas

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "SpatiaLite Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/spatialite-users/v-RCCrx5GoM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> spatialite-use...@googlegroups.com.
> To post to this group, send email to spatiali...@googlegroups.com.
> Visit this group at http://groups.google.com/group/spatialite-users.
> For more options, visit https://groups.google.com/d/optout.



--
Disclaimer: Any errors in spelling, tact, or fact are transmission errors.