JDK-8285647 : serviceability/sa/ClhsdbFindPC.java#no-xcomp-core failed with "RuntimeException: 'Java_jdk_test_lib_apps_LingeredApp_crash' missing"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 19
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • Submitted: 2022-04-26
  • Updated: 2023-08-22
  • Resolved: 2023-08-22
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
The following test failed in the JDK19 CI:

serviceability/sa/ClhsdbFindPC.java#no-xcomp-core

Here's a snippet from the log file:

----------System.err:(28/1387)----------
 stdout: [ + 
];
 stderr: [ + 
]
 exitValue = -1

java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'Java_jdk_test_lib_apps_LingeredApp_crash' missing from stdout/stderr 

	at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:306)
	at ClhsdbFindPC.main(ClhsdbFindPC.java:328)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:828)
Caused by: java.lang.RuntimeException: 'Java_jdk_test_lib_apps_LingeredApp_crash' missing from stdout/stderr 

	at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:340)
	at ClhsdbLauncher.runCmd(ClhsdbLauncher.java:166)
	at ClhsdbLauncher.runOnCore(ClhsdbLauncher.java:225)
	at ClhsdbFindPC.runTest(ClhsdbFindPC.java:318)
	at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:129)
	... 5 more

JavaTest Message: Test threw exception: java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'Java_jdk_test_lib_apps_LingeredApp_crash' missing from stdout/stderr 

JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'Java_jdk_test_lib_apps_LingeredApp_crash' missing from stdout/stderr
----------rerun:(33/6700)*----------


The stdout log does show this:

# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-ea+20-1343, interpreted mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# C  [libLingeredApp.so+0x73c]  Java_jdk_test_lib_apps_LingeredApp_crash+0xc
#

and "Java_jdk_test_lib_apps_LingeredApp_crash" appears to be
what's being looked for.
Comments
Redoing as closed as duplicate instead of resolved.
22-08-2023

This is fixed by: JDK-8285792: Posix signal handler modification checking issues. ...so should close as a duplicate of that. JDK-8283337 fixed an issue caused by JDK-8279124, but we discovered additional problems relating to the periodic check triggered by -Xcheck:jni which were fixed in JDK-8285792.
22-08-2023

[~kevinw] Any plans to address this issue?
17-08-2023

This could be related to JDK-8283337, and the fix for it may not be complete.
28-04-2022

I think I know what’s going on. The extra output seems to be due to using -Xcheck:jni. I think the reason it wasn’t noticed before is because the test only fails if the main SIGSEGV line gets messed up, and this is very rare. We need to avoid running LingeredApp with -Xcheck:jni.
27-04-2022

There are two odd things in the log I can't explain. First, when the forced crash happens, I see a bunch of output like the following: Warning: SIGILL handler modified! Signal Handlers: SIGSEGV: crash_handler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGBUS: crash_handler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGFPE: crash_handler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGPIPE: javaSignalHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGXFSZ: javaSignalHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGILL: crash_handler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGUSR2: SR_handler in libjvm.so, mask=00100000000000000000000000000000, flags=SA_RESTART|SA_SIGINFO SIGHUP: UserHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGINT: UserHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGTERM: UserHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGQUIT: UserHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO SIGTRAP: crash_handler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO Consider using jsig library. This is something that is not normally seen. Second. When clhsdb is run on the core file for the first time, normally it looks like: Opening core file, please wait... hsdb> hsdb> + verbose true hsdb> + findpc 0x0000fffe8007073c Address 0x0000fffe8007073c: Java_jdk_test_lib_apps_LingeredApp_crash + 0xc hsdb> + quit This is a very trivial first step to look up the symbol of the crash address. However, instead we are getting: Opening core file, please wait... hsdb> hsdb> + verbose true hsdb> + hsdb> + hsdb> + quit malformed history reference The "malformed history reference" commands from clhsdb when trying to reference the shell history, which should only happen if there is a '!' somewhere in the command. You can see from the echoes output that there is not, and also the "findpc" command is missing. So something went very wrong with the test in setting up the command to pass to clhsdb. I think I see why. In the core dump output there is the following: # SIGSEGV (0xb) at pc=0x0000fffd4c01073cWarning: SIGSEGV handler modified! , pid=2298512, tid=2298515 Normally it should look like: # SIGSEGV (0xb) at pc=0x0000fffe8007073c, pid=2879799, tid=2879802 So the test is having trouble parsing this because of the extra output, and probably thinks the address is "0x0000fffd4c01073cWarning: SIGSEGV handler modified!". The '!' at the end is ending up in the findpc command, thus the "malformed history reference". So the question is, why all this extra output when hotspot crashes, and why is this test run the only time we've seen the extra output?
27-04-2022