At the time, the JVM was near a heap-full condition due to what the application was doing, so I suspect that the call to env->NewIntArray(2) returned a NULL instead of a valid pointer, so the following line's call to SetIntArrayRegion with the returned array pointer caused the SIGSEGV.
Heap statistics from the crash file are:
OutOfMemory and StackOverflow Exception counts:
OutOfMemoryError java_heap_errors=6
heap address: 0x00000006eb800000, size: 3400 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
Narrow klass base: 0x0000000000000000, Narrow klass shift: 3
Compressed class space size: 1073741824 Address: 0x00000007c0000000
Heap:
PSYoungGen total 978944K, used 801792K [0x0000000779300000, 0x00000007c0000000, 0x00000007c0000000)
eden space 801792K, 100% used [0x0000000779300000,0x00000007aa200000,0x00000007aa200000)
from space 177152K, 0% used [0x00000007aa200000,0x00000007aa200000,0x00000007b4f00000)
to space 172032K, 0% used [0x00000007b5800000,0x00000007b5800000,0x00000007c0000000)
ParOldGen total 2321408K, used 2321089K [0x00000006eb800000, 0x0000000779300000, 0x0000000779300000)
object space 2321408K, 99% used [0x00000006eb800000,0x00000007792b0668,0x0000000779300000)
Metaspace used 34267K, capacity 34646K, committed 35072K, reserved 1081344K
class space used 3801K, capacity 3967K, committed 4096K, reserved 1048576K
The waitEvents() method should be bombproofed to check memory allocation calls for success, and return appropriate status (or schedule throwing a java.lang.OutOfMemoryError) if the allocates do not succeed.
This was on Fedora Core 37 Linux, kernel 6.2.10-200.fc37.x86_64, and Java runtime:
openjdk version "1.8.0_362"
OpenJDK Runtime Environment (build 1.8.0_362-b09)
OpenJDK 64-Bit Server VM (build 25.362-b09, mixed mode)
and the official 2.9.4 release of JSSC (binary distro from this website).
My JVM crashed with a SIGSEGV with the following stack traces in the JVM crash file:
Stack: [0x00007f871eb27000,0x00007f871ec27000], sp=0x00007f871ec25890, free space=1018k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x75678c] jni_SetIntArrayRegion+0xfc C [libjssc.so+0x7e2c] Java_jssc_SerialNativeInterface_waitEvents+0x1ac
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J 2054 jssc.SerialNativeInterface.waitEvents(J)[[I (0 bytes) @ 0x00007f879ff84478 [0x00007f879ff84440+0x38] J 2960% C2 jssc.SerialPort$LinuxEventThread.run()V (550 bytes) @ 0x00007f87a03f34ec [0x00007f87a03f2bc0+0x92c] v ~StubRoutines::call_stub
At the time, the JVM was near a heap-full condition due to what the application was doing, so I suspect that the call to env->NewIntArray(2) returned a NULL instead of a valid pointer, so the following line's call to SetIntArrayRegion with the returned array pointer caused the SIGSEGV.
Heap statistics from the crash file are:
OutOfMemory and StackOverflow Exception counts: OutOfMemoryError java_heap_errors=6
heap address: 0x00000006eb800000, size: 3400 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 Narrow klass base: 0x0000000000000000, Narrow klass shift: 3 Compressed class space size: 1073741824 Address: 0x00000007c0000000
Heap: PSYoungGen total 978944K, used 801792K [0x0000000779300000, 0x00000007c0000000, 0x00000007c0000000) eden space 801792K, 100% used [0x0000000779300000,0x00000007aa200000,0x00000007aa200000) from space 177152K, 0% used [0x00000007aa200000,0x00000007aa200000,0x00000007b4f00000) to space 172032K, 0% used [0x00000007b5800000,0x00000007b5800000,0x00000007c0000000) ParOldGen total 2321408K, used 2321089K [0x00000006eb800000, 0x0000000779300000, 0x0000000779300000) object space 2321408K, 99% used [0x00000006eb800000,0x00000007792b0668,0x0000000779300000) Metaspace used 34267K, capacity 34646K, committed 35072K, reserved 1081344K class space used 3801K, capacity 3967K, committed 4096K, reserved 1048576K
The waitEvents() method should be bombproofed to check memory allocation calls for success, and return appropriate status (or schedule throwing a java.lang.OutOfMemoryError) if the allocates do not succeed.
This was on Fedora Core 37 Linux, kernel 6.2.10-200.fc37.x86_64, and Java runtime: openjdk version "1.8.0_362" OpenJDK Runtime Environment (build 1.8.0_362-b09) OpenJDK 64-Bit Server VM (build 25.362-b09, mixed mode)
and the official 2.9.4 release of JSSC (binary distro from this website).