The following test failed in the JDK20 CI:
applications/kitchensink/Kitchensink8H.java
Here's a snippet from the log file:
[2022-10-14T09:54:35.607376Z] Gathering output for process 34285
[2022-10-14T09:54:37.996252Z] Waiting for completion for process 34285
[2022-10-14T09:54:37.997303Z] Waiting for completion finished for process 34285
Output and diagnostic info for process 34285 was saved into 'pid-34285-output.log'
[stress.process.out] #
[stress.process.out] # A fatal error has been detected by the Java Runtime Environment:
[stress.process.out] #
[stress.process.out] # SIGSEGV (0xb) at pc=0x00000001031abcb0, pid=34273, tid=12547
[stress.process.out] #
[stress.process.out] # JRE version: Java(TM) SE Runtime Environment (20.0+19) (fastdebug build 20-ea+19-1363)
[stress.process.out] # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-ea+19-1363, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
[stress.process.out] # Problematic frame:
[stress.process.out] # V [libjvm.dylib+0xc8fcb0] MallocTracker::record_free(void*)+0x18c
[stress.process.out] #
[stress.process.out] # Core dump will be written. Default location: core.34273
[stress.process.out] #
[stress.process.out] # JFR recording file will be written. Location: /System/Volumes/Data/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S80283/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ffeefe78-25e7-4d47-aa22-3134a81690df/runs/28bd1877-bd61-42bc-a125-ae9ad34b0b6c/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink8H_java/scratch/0/hs_err_pid34273.jfr
[stress.process.out] #
[stress.process.out] Unsupported internal testing APIs have been used.
[stress.process.out]
[stress.process.out] # An error report file with more information is saved as:
[stress.process.out] # /System/Volumes/Data/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S80283/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ffeefe78-25e7-4d47-aa22-3134a81690df/runs/28bd1877-bd61-42bc-a125-ae9ad34b0b6c/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink8H_java/scratch/0/hs_err_pid34273.log
[stress.process.out] #
[stress.process.out] # If you would like to submit a bug report, please visit:
[stress.process.out] # https://bugreport.java.com/bugreport/crash.jsp
[stress.process.out] #
[2022-10-14T09:57:59.031653Z] Gathering output for process 34302
[2022-10-14T09:57:59.732424Z] Waiting for completion for process 34302
[2022-10-14T09:57:59.732540Z] Waiting for completion finished for process 34302
Output and diagnostic info for process 34302 was saved into 'pid-34302-output.log'
Here's the crashing thread's stack:
--------------- T H R E A D ---------------
Current thread (0x0000000134006340): WorkerThread "GC Thread#0" [stack: 0x000000016f820000,0x000000016fa23000] [id=12547]
Stack: [0x000000016f820000,0x000000016fa23000], sp=0x000000016fa22cb0, free space=2059k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.dylib+0xc8fcb0] MallocTracker::record_free(void*)+0x18c
V [libjvm.dylib+0xda3850] os::free(void*)+0xf8
V [libjvm.dylib+0x835488] InstanceKlass::get_jmethod_id(methodHandle const&)+0x2e0
V [libjvm.dylib+0xd004b4] Method::jmethod_id()+0x74
V [libjvm.dylib+0xd50574] nmethod::unlink()+0x114
V [libjvm.dylib+0xdc934c] CodeCacheUnloadingTask::work(unsigned int)+0x70
V [libjvm.dylib+0x71b4e4] G1ParallelCleaningTask::work(unsigned int)+0x74
V [libjvm.dylib+0x10e3808] WorkerThread::run()+0x94
V [libjvm.dylib+0xfe96b0] Thread::call_run()+0x220
V [libjvm.dylib+0xda88d0] thread_native_entry(Thread*)+0x160
C [libsystem_pthread.dylib+0x74ec] _pthread_start+0x94
siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x0000979245543410
The crashing thread is WorkerThread "GC Thread#0", GC is doing
a CodeCacheUnloadingTask so we've called nmethod::unlink() and
the "interesting" crashing frames are:
V [libjvm.dylib+0xc8fcb0] MallocTracker::record_free(void*)+0x18c
V [libjvm.dylib+0xda3850] os::free(void*)+0xf8
V [libjvm.dylib+0x835488] InstanceKlass::get_jmethod_id(methodHandle const&)+0x2e0
V [libjvm.dylib+0xd004b4] Method::jmethod_id()+0x74
and these functions are often investigated by Runtime... So this bug
could start in GC, Compiler or Runtime for initial triage... choices...
I think I'll start this bug off in Runtime since the SIGSEGV is in
MallocTracker::record_free and maybe there's something that
should be hardened in that function to get more information when
passed bad info (rather than a SIGSEGV)...
Another interesting point is that I think we've only recently added
macosx-aarch64 machines to Tier8 so this might not be due to a
recent change...