JVM crash with current versions

[Ion Tichy]

Hi all,

I am using libspatialite via JDBC. We have a wrapper around a JDBC Connection class, which loads the extension via the following statement:

SELECT load_extension('/usr/local/lib/mod_spatialite');

This used to work with sqlite 3.28.0 and libspatialite 4.3. We used to instruct our developers on Mac here to install those using homebrew. Unfortunately homebrew has stopped to support those versions. When running the above statement via JDBC with the current versions, the JVM crashes with the following error:

#  SIGSEGV (0xb) at pc=0x00007fff26064882, pid=16350, tid=6147

#

# JRE version: OpenJDK Runtime Environment AdoptOpenJDK (11.0.9.1+1) (build 11.0.9.1+1)

# Java VM: OpenJDK 64-Bit Server VM AdoptOpenJDK (11.0.9.1+1, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64)

# Problematic frame:

# C  [libsqlite3.dylib+0xc6882]  checkMutexEnter+0x12

I tried falling back to older versions provided by homebrew using the `homebrew extract` command, but the latest version of libspatialite that homebrew even supplies in this manner is 5.0.0, which also produces the above error. As a result we are currently 100% stuck, not being able to do any work with a bunch of databases that are pivotal for our development process.

I tried to compile older versions of libspatialite from source, but the dilemma is that these installations do not produce `mod_spatialite.dylib` which seems to be essential for things to work on our end (only mod_spatialite.so is produced on mac). When installing the package via homebrew, somehow the dylib was produced, but I have not been able to find out how to parametrise the configure command with switches or CFLAGS to make this happen. Also tried any number of older versions of sqlite in combination to no avail. 

Does anyone have an insight into what causes this problem on Macs and a workaround? Or how to install libspatialite on Mac in a way from source that produces the dynamic library for `mod_spatialite`?

Any pointers are greatly appreciated.

[andrea antonello]

Hi Ion, 

sorry for the very short reply, I am on the road. But it might help, so...

I have been installing spatialite on mac recently using macports and it did work great also with jdk 11 and 14. 

It might be worth a try. 

Best,

Andrea

--
You received this message because you are subscribed to the Google Groups "SpatiaLite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spatialite-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialite-users/684604f6-cb07-488a-a6d0-a254a5c402c3n%40googlegroups.com.

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

On Sat, 23 Oct 2021 02:23:18 -0700 (PDT), 'Ion Tichy' via SpatiaLite
Users wrote:
> # Problematic frame:
> # C [libsqlite3.dylib+0xc6882] checkMutexEnter+0x12
>

few months ago we had a ticket reporting a possibly related issue:

https://www.gaia-gis.it/fossil/libspatialite/tktview?name=3df8b6c54f

as you can see the problem was caused by the CLANG compiler when
activating a Mutex lock, an operation that libspatialite performs
just in a single point when establishing a new connection.

curiously enough the same problem never arose when using a copy
of libspatialite compiled by GCC; it could be just a coincidence,
but it's worth noting that standard compiler on Mac is just CLANG.

we resolved the bug (that was reported on Windows) by avoiding
to call Mutexes provided by libpthread and always using the
native platform implementation as a full replacement, but
this isn't obviously a viable solution on Mac.

> I tried to compile older versions of libspatialite from source, but
> the dilemma is that these installations do not produce
> `mod_spatialite.dylib` which seems to be essential for things to work
> on our end (only mod_spatialite.so is produced on mac).
>

.dylib is a strange thing that only Mac has.
my personal experience on Mac goes back many years, but if I remember
correctly simply renaming mod_spatialite.so as mod_spatialite.dylib
(or better yet, define a symlink) should probably solve this issue.

if you are loocking for a more elegant solution it seems that
the Mac compiler simply require to receive a -dynamiclib
directive in order to create a .dylib instead of a .so

please see:
https://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-macos

bye Sandro

[Ion Tichy]

Thanks for the replies! As it happens so often, the problem was solved a few minutes after desperation drove me to seek help. Here the solution in case someone else runs into this:

The problem was that the JDBC driver that our connection class was based on was outdated. With the newest version of xenia's JDBC driver, our driver now works perfectly. 

[Ion Tichy]

<snip>

simply renaming mod_spatialite.so as mod_spatialite.dylib 
(or better yet, define a symlink) should probably solve this issue. 

</snip>

That is not an option (I actually tried this). The format is different. 

<snip>

f you are loocking for a more elegant solution it seems that 
the Mac compiler simply require to receive a -dynamiclib 
directive in order to create a .dylib instead of a .so 

</snip>

That also doesn't work (I tried it) as autoconfig will balk and quit with some comment that cross-platform compilation is supposed to be solved with --host, --build and --target flags. Which I tried also but still no mod_spatialite.dylib (however, the libspatialite.dylib is produced). 

On Saturday, October 23, 2021 at 11:41:52 AM UTC+1 sandro furieri wrote: