GeezerVison is showing github.com — mvn install causes SIGSEGV in libpthread, OpenJDK 8.0_151-b12, Linux x86_64 · Issue #129 · lmdbjava/lmdbjava
mvn install causes SIGSEGV in libpthread, OpenJDK 8.0_151-b12, Linux x86_64 #129DescriptionHello,
I seem to be having difficulties building the library:
mvn install
...
[INFO] Running org.lmdbjava.ResultCodeMapperTest
[INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.037 s - in org.lmdbjava.ResultCodeMapperTest
[INFO] Running org.lmdbjava.TxnTest
[INFO] Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.199 s - in org.lmdbjava.TxnTest
[INFO] Running org.lmdbjava.LibraryTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 s - in org.lmdbjava.LibraryTest
[INFO] Running org.lmdbjava.MetaTest
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 s - in org.lmdbjava.MetaTest
[INFO] Running org.lmdbjava.EnvTest
[INFO] Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.072 s - in org.lmdbjava.EnvTest
[INFO] Running org.lmdbjava.VerifierTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.005 s - in org.lmdbjava.VerifierTest
[INFO] Running org.lmdbjava.MaskedFlagTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 s - in org.lmdbjava.MaskedFlagTest
[INFO] Running org.lmdbjava.TutorialTest
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f5c6e2a9ae5, pid=25717, tid=0x00007f5c6e6b5700
#
# JRE version: OpenJDK Runtime Environment (8.0_151-b12) (build 1.8.0_151-b12)
# Java VM: OpenJDK 64-Bit Server VM (25.151-b12 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libpthread.so.0+0x9ae5] __pthread_mutex_lock_full+0x335
#
# Core dump written. Default location: /home/karm/workspaceRH/lmdbjava/core or core.25717
#
# An error report file with more information is saved as:
# /home/karm/workspaceRH/lmdbjava/hs_err_pid25717.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted (core dumped)
I originally suspected it might have something to do with classloading and ability of the gluecode to load .so files so I tried to add
+<forkCount>0</forkCount>
without any luck. It just crashes the other instance.
Backtrace of the offending thread
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f5c6d8e84da in __GI_abort () at abort.c:89
#2 0x00007f5c6d185fa9 in os::abort (dump_core=<optimized out>) at /usr/src/debug/java-1.8.0-openjdk-1.8.0.151-1.b12.fc25.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:1513
#3 0x00007f5c6d3bc3d8 in VMError::report_and_die (this=this@entry=0x7f5c6e6b1090) at /usr/src/debug/java-1.8.0-openjdk-1.8.0.151-1.b12.fc25.x86_64/openjdk/hotspot/src/share/vm/utilities/vmError.cpp:1060
#4 0x00007f5c6d18fac5 in JVM_handle_linux_signal (sig=sig@entry=11, info=info@entry=0x7f5c6e6b1330, ucVoid=ucVoid@entry=0x7f5c6e6b1200, abort_if_unrecognized=abort_if_unrecognized@entry=1)
at /usr/src/debug/java-1.8.0-openjdk-1.8.0.151-1.b12.fc25.x86_64/openjdk/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:541
#5 0x00007f5c6d183228 in signalHandler (sig=11, info=0x7f5c6e6b1330, uc=0x7f5c6e6b1200) at /usr/src/debug/java-1.8.0-openjdk-1.8.0.151-1.b12.fc25.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:4440
#6 <signal handler called>
#7 0x00007f5c6e2a9ae5 in __pthread_mutex_lock_full (mutex=0x7f5c0caf2040) at ../nptl/pthread_mutex_lock.c:272
#8 0x00007f5c6e2a9eb5 in __GI___pthread_mutex_lock (mutex=mutex@entry=0x7f5c0caf2040) at ../nptl/pthread_mutex_lock.c:73
#9 0x00007f5c0c39def2 in mdb_txn_renew0 (txn=txn@entry=0x7f5c665672f0) at mdb.c:2749
#10 0x00007f5c0c39f494 in mdb_txn_begin (env=0x7f5c665671a0, parent=0x0, flags=0, ret=0x7f5c0cb217e8) at mdb.c:2907
#11 0x00007f5c0cb4668c in ?? ()
#12 0x0000000000000000 in ?? ()
There is a full backtrace over all threads:
gdb_backstrace.log
and an hs dump log:
hs_err_pid25717.log. I do have the core file itself archived and I can provide it on request.
Thank you for any guidance
Best regards
K Activitybp-alex commented on May 31, 2019 Historically I've seen similar issues where LmdbJava's test cases fail quite late (and unexpectedly) due to exhaustion of Env and/or reader space. Typically I fix that by judiciously minimising readers and closing Envs (eg 5ccb6c5).
What I suspect is happening here is the significant increase to the default setting for an Env maximum readers (see #114) has meant the TutorialTest is allocating far more readers to the forked JVM test process than it used to.
I looked at modifying TutorialTest but it's trying to demonstrate idiomatic use of the Env.open(..) method. There is no overloaded version which allows passing a max readers, as that's what the Env.Builder is for. I could change TutorialTest to use a private openEnv method but it becomes less readable for new users. Still, that's probably the appropriate solution here rather than having users confronted with SIGSEGV for simply running the project's test suite.
Can you try mvn '-Dtest=!TutorialTest' test on your machine to see if excluding the TutorialTest results in success? bp-alex commented on Jun 1, 2019 I decided to introduce a helper method to TutorialTest. I'd rather not have the test suit crash given the confusion it creates.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|