Bug ID: JDK-8221616 gtest/GTestWrapper.java crashed due to SIGSEGV on Linux-X64

Type: Bug
Component: hotspot
Sub-Component: gc
Affected Version: 13

Priority: P4
Status: Closed
Resolution: Cannot Reproduce
OS: linux_ubuntu
CPU: x86_64

Submitted: 2019-03-28
Updated: 2019-03-29
Resolved: 2019-03-29

The following test failed in my stress testing for 8153224:

gtest/GTestWrapper.java

Here's a snippet from the log file:

[ RUN      ] CollectorPolicy.young_cmd_other_vm_test
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000000065, pid=20583, tid=20583
#
# JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug build 13-internal+0-2019-03-27-1030544.dcubed.null)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-internal+0-2019-03-27-1030544.dcubed.null, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C  0x0000000000000065
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /work/shared/bug_hunt/8183909/8153224_exp_for_jdk13/build/linux-x86_64-normal-server-fastdebug/test-support/jtreg_open_test_hotspot_jtreg_tier1/gtest/GTestWrapper/core.20583)
#
# An error report file with more information is saved as:
# /work/shared/bug_hunt/8183909/8153224_exp_for_jdk13/build/linux-x86_64-normal-server-fastdebug/test-support/jtreg_open_test_hotspot_jtreg_tier1/gtest/GTestWrapper/hs_err_pid20583.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.
#
Current thread is 20583
Dumping core ...
/work/shared/bug_hunt/8183909/8153224_exp_for_jdk13/open/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp:245: Failure
Death test: child_CollectorPolicy_young_cmd_()
    Result: died but not with expected exit code:
            Terminated by signal 6 (core dumped)
Actual msg:
[  DEATH   ] OKIDOKI
[  FAILED  ] CollectorPolicy.young_cmd_other_vm_test (4877 ms)

The stack from the hs_err_pid is pretty useless:

---------------  T H R E A D  ---------------
    
Current thread (0x0000000000f64800):  JavaThread "main" [_thread_in_native, id=20583, s

Stack: [0x00007ffe93192000,0x00007ffe93292000],  sp=0x00007ffe9328f1c8,  free space=101
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM co
C  0x0000000000000065


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

Neither the hs_err_pid file or the core file were helpful in determining a way to investigate this crash. I tried an overnight test run to reproduce this failure without any luck either. I'm closing this bug as "Cannot Reproduce".
29-03-2019
I kicked off a doit_loop run for this test using fastdebug bits last night: $ grep -v PASS doit_loop.log Run #2316... $ elapsed_times start doit_loop.log start 0 seconds doit_loop.log 13 hours 27 minutes 44 seconds The machine is doing jdk-13+14 stress testing so it's a bit busy: $ uptime 20:12:55 up 20 days, 8:48, 6 users, load average: 64.15, 62.85, 58.46 $ uptime 09:46:53 up 20 days, 22:22, 6 users, load average: 52.51, 35.32, 44.00 So in about 13.5 hours the test passed 2315 times. It does not look like this failure is going to be reproducible.
29-03-2019
Here are my logs for my 8153224 stress testing on Linux-X64: $ unzip -l 8153224.v2.00_linux.8221616.zip Archive: 8153224.v2.00_linux.8221616.zip Length Date Time Name --------- ---------- ----- ---- 70184 2019-03-27 17:02 8153224.v2.00_3/failures.linux-x86_64/hs_err_pid20583.log 175859 2019-03-27 17:02 8153224.v2.00_3/failures.linux-x86_64/GTestWrapper.jtr.fastdebug 35928 2019-03-28 19:36 8153224.v2.00_3/failures.linux-x86_64/threads.log.20583 --------- ------- 281971 3 files Updated to include a threads.log from the core file. Here's the crashing thread's stack (not much help): Thread 1 (Thread 0x2b4aec599480 (LWP 20583)): #0 0x00002b4aeebda428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x00002b4aeebdc02a in __GI_abort () at abort.c:89 #2 0x00002b4aedcbb7c1 in os::abort (dump_core=<optimized out>, siginfo=<optimized out>, context=<optimized out>) at /work/shared/bug_hunt/8183909/8153224_exp_for_jdk13/open/src/hotspot/os/linux/os_linux.cpp:1373 #3 0x00002b4aee0555b6 in VMError::report_and_die (id=<optimized out>, message=<optimized out>, detail_fmt=0x2b4aee358edb "%s", detail_args=0x7ffe9328e9d8, thread=0xf64800, pc=<optimized out>, siginfo=0x7ffe9328ed70, context=0x7ffe9328ec40, filename=0x0, lineno=0, size=0) at /work/shared/bug_hunt/8183909/8153224_exp_for_jdk13/open/src/hotspot/share/utilities/vmError.cpp:1561 #4 0x00002b4aee0560cb in VMError::report_and_die (thread=0x8, sig=20583, pc=0x5 <error: Cannot access memory at address 0x5>, siginfo=0x2b4aeebda428 <__GI_raise+56>, context=0x7ffe9328ec40, detail_fmt=0x6 <error: Cannot access memory at address 0x6>) at /work/shared/bug_hunt/8183909/8153224_exp_for_jdk13/open/src/hotspot/share/utilities/vmError.cpp:1262 #5 0x00002b4aee0560fe in VMError::report_and_die (thread=0x5067, sig=20583, pc=0x6 <error: Cannot access memory at address 0x6>, siginfo=0x2b4aeebda428 <__GI_raise+56>, context=0x4) at /work/shared/bug_hunt/8183909/8153224_exp_for_jdk13/open/src/hotspot/share/utilities/vmError.cpp:1268 #6 0x00002b4aec57f150 in ?? () #7 0x00007ffe9328ebf0 in ?? () #8 0x00002b4aedcc965e in JVM_handle_linux_signal (sig=11, info=0x7ffe9328ed70, ucVoid=0x7ffe9328ec40, abort_if_unrecognized=<optimized out>) at /work/shared/bug_hunt/8183909/8153224_exp_for_jdk13/open/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:605 Backtrace stopped: previous frame inner to this frame (corrupt stack?)
28-03-2019
I searched Mach5 and I can't find a failure of gtest/GTestWrapper.java that looks like this one. I wasn't able to do this search this morning due to a Mach5 service window; normally, I try not to file a bug outside of hotspot/runtime if I can't find a sighting in more official bits. I filed this bug in hotspot/gc because we're executing the following internal test: "CollectorPolicy.young_cmd_other_vm_test "
28-03-2019
According to the hs_err log no GC event occurred.
28-03-2019