SIGSEGV during scan

ClassGraph scan, using version 4.6.18, is called at runtime with the following method:

    private static Set<Class> getSubclasses(Class clazz) {
        try (ScanResult scanResult = new ClassGraph()
                .enableClassInfo()
                .ignoreClassVisibility()
                .enableSystemJarsAndModules()
                .whitelistPackages(clazz.getPackage().getName())
                .scan()) {
            return new HashSet<>(scanResult.getSubclasses(clazz.getName()).loadClasses());
        }
        catch (Exception e) {
            LOGGER.error("Failed to scan subclasses of {}", clazz, e);
        }
        return Collections.emptySet();
    }

Java application crashes with:

Current thread (0x00007fe1543b7000):  JavaThread "ClassGraph-worker-832" daemon [_thread_in_Java, id=279129, stack(0x00007fe02d73d000,0x00007fe02d83e000)]

Stack: [0x00007fe02d73d000,0x00007fe02d83e000],  sp=0x00007fe02d83c198,  free space=1020k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 7462 c2 java.util.TimSort.gallopRight(Ljava/lang/Object;[Ljava/lang/Object;IIILjava/util/Comparator;)I java.base@10.0.2 (335 bytes) @ 0x00007fe269cdffcf [0x00007fe269cdf380+0x0000000000000c4f]

[error occurred during error reporting (printing native stack), id 0xb]

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00000000bfffffd2

Coredump shows the following stacktrace:

"MainThread" #31 prio=5 tid=0x00007fe27cc2d000 nid=0x3b445 waiting on condition [0x00007fe162eef000]
   java.lang.Thread.State: WAITING (parking)
   JavaThread state: _thread_blocked
 - jdk.internal.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise)
        - parking to wait for <0x00000000e03e5910> (a java/util/concurrent/FutureTask)
 - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, line=194 (Compiled frame)
 - java.util.concurrent.FutureTask.awaitDone(boolean, long) @bci=208, line=447 (Interpreted frame)
 - java.util.concurrent.FutureTask.get() @bci=13, line=190 (Compiled frame)
 - io.github.classgraph.ClassGraph.scan(java.util.concurrent.ExecutorService, int) @bci=25, line=1135 (Inte
rpreted frame)
 - io.github.classgraph.ClassGraph.scan(int) @bci=12, line=1176 (Interpreted frame)
 - io.github.classgraph.ClassGraph.scan() @bci=4, line=1188 (Interpreted frame)
 - com.app.Subclasses.getSubclasses(java.lang.Class) @bci=33, line=101 (Interpreted frame)
<truncated>

Most ClassGraph-worker threads show:

"ClassGraph-worker-837" #898 daemon prio=5 tid=0x00007fe040006000 nid=0x4425e waiting on condition [0x00007fe02de8e000]
   java.lang.Thread.State: WAITING (parking)
   JavaThread state: _thread_blocked
 - jdk.internal.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise)
        - parking to wait for <0x00000000e03e4b28> (a java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject)
 - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, line=194 (Compiled frame)
 - java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await() @bci=42, line=2075 (Compiled frame)
 - java.util.concurrent.LinkedBlockingQueue.take() @bci=29, line=435 (Compiled frame)
 - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=147, line=1061 (Compiled frame)
 - java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @bci=26, line=1121 (Compiled frame)
 - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=635 (Compiled frame)
 - java.lang.Thread.run() @bci=11, line=844 (Compiled frame)

The ClassGraph-worker thread that crashed:

"ClassGraph-worker-832" #893 daemon prio=5 tid=0x00007fe1543b7000 nid=0x44259 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_java

# printed frames
"ClassGraph-worker-832" #893 daemon prio=5 tid=0x00007fe1543b7000 nid=0x44259 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_java
0x00007fe2855b21d7      __GI_raise + 0x37
0x00007fe284f045d4      _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x2e4
0x00007fe284f04f7b      _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b
0x00007fe284f04fae      _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e
0x00007fe284f052ff      _ZL13crash_handleriP7siginfoPv + 0xef
0x00007fe285d60370              ????????
0x00007fe284f00d32      _ZN7VMError18print_native_stackEP12outputStream5frameP6ThreadPci + 0x1f2
0x00007fe284f0318d      _ZN7VMError6reportEP12outputStreamb + 0x23bd
0x00007fe284f04452      _ZN7VMError14report_and_dieEiPKcS1_P13__va_list_tagP6ThreadPhPvS7_S1_im + 0x162
0x00007fe284f04f7b      _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_PKcz + 0x8b
0x00007fe284f04fae      _ZN7VMError14report_and_dieEP6ThreadjPhPvS3_ + 0x1e
0x00007fe284d162aa      JVM_handle_linux_signal + 0x14a
0x00007fe284d0aea8      _Z13signalHandleriP7siginfoPv + 0x38

Crashes started happening after switching JDK versions from Oracle’s 1.8.0_u162 to 10.0.2. Here are the Java options to run application: -Xms1G -Xmx1G -XX:NewRatio=1 -XX:SurvivorRatio=4 -XX:+UseParallelGC. Here is host information: Intel® Xeon® Silver 4116 CPU @ 2.10GHz, 48 cores, 92G, CentOS Linux release 7.3.1611 (Core)

Please note, I am currently working on getting verbose logging enabled to upload. I could not replicate this issue in a unit test. The crashes do not occur after every restart and happen maybe once or twice a week for the same application. I did not upload the coredump because of sensitive information.

Please let me know if more information is required in the meantime while I try to get verbose logging.

[zako]

Thanks for the links. For posterity, jhsdb was helpful to extract stack traces: https://docs.oracle.com/javase/9/tools/jhsdb.htm. I will investigate one of the core dumps more thoroughly to see if anything else is helpful.

Disabling JIT using -Xint is an interesting one. I will not be able to disable for all but maybe for some of the applications that are not heavily used.

[zako]

No luck reproducing the issue locally or even remotely on an application that previously failed. This happens once a day on a couple of applications out of 500.

Fortunately, JDK11 roll out is already in the works and I will update these applications and see if the issue still persists.