JDK-8310919 : runtime/ErrorHandling/TestAbortVmOnException.java times out due to core dumps taking a long time on OSX
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 22
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2023-06-26
  • Updated: 2023-12-29
  • Resolved: 2023-06-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 21 JDK 22
21.0.3Fixed 22 b05Fixed
Related Reports
Relates :  
JDK-8264899 - C1: -XX:AbortVMOnException does not work if all methods in the call stack are compiled with C1 and there are no exception handlers
Relates :  
JDK-8267433 - Core dumps on OSX sometimes take a very long time
Description
The following test timed out in the JDK22 CI:

runtime/ErrorHandling/TestAbortVmOnException.java

Here's a snippet from the log file:

#section:driver
----------messages:(10/316)----------
command: driver TestAbortVmOnException
reason: User specified action: run driver TestAbortVmOnException 
started: Mon Jun 26 13:23:36 GMT 2023
Mode: agentvm
Agent id: 6
Timeout refired 480 times
Timeout information:
--- Timeout information end.
finished: Mon Jun 26 13:36:02 GMT 2023
elapsed time (seconds): 745.706
----------configuration:(14/1990)----------

<snip>

result: Error. Agent error: java.lang.Exception: Agent 6 timed out with a timeout of 480 seconds; check console log for any additional details


Since this is a new test recently added by:

JDK-8264899 C1: -XX:AbortVMOnException does not work if all methods in the call stack are compiled with C1 and there are no exception handlers

I'm starting this bug off in hotspot/compiler for initial triage.
Comments
Fix request [21u] I backport this to keep the 21u test suite up-to-date. No risk, only a test change. Clean backport. Test passes. SAP nightly testing passed.
29-12-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/102 Date: 2023-12-28 13:25:02 +0000
28-12-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/14704 Date: 2023-06-29 06:35:15 +0000
29-06-2023
Thanks [~dholmes]. It is probably a good idea anyway since the test "creates" three of them every time by default.
29-06-2023
Interesting, do we have a tracking bug for this issue?
29-06-2023
This is simply the problem of core dumps taking a long time to generate on macOS i.e. the test should specifiy -XX:-CreateCoredumpOnCrash
29-06-2023
Changeset: e5744b81 Author: Damon Fenacci <dfenacci@openjdk.org> Date: 2023-06-29 12:07:54 +0000 URL: https://git.openjdk.org/jdk/commit/e5744b8120548a161f75aa098826a6798d85f90f
29-06-2023
The test seems to wait for the output of the process it spawned: "AgentVMThread" #115 prio=5 tid=0x000000012283f810 nid=14931 waiting on condition [0x000000017189a000] java.lang.Thread.State: WAITING (parking) JavaThread state: _thread_blocked - jdk.internal.misc.Unsafe.park(boolean, long) @bci=0 (Interpreted frame) - parking to wait for <0x00000006c000d588> (a java/util/concurrent/FutureTask) - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=27, line=221 (Interpreted frame) - java.util.concurrent.FutureTask.awaitDone(boolean, long) @bci=208, line=500 (Interpreted frame) - java.util.concurrent.FutureTask.get() @bci=13, line=190 (Interpreted frame) - jdk.test.lib.process.OutputBuffer$LazyOutputBuffer$StreamTask.get() @bci=4, line=109 (Interpreted frame) - jdk.test.lib.process.OutputBuffer$LazyOutputBuffer.getStdout() @bci=4, line=139 (Interpreted frame)It seems - jdk.test.lib.process.OutputAnalyzer.getStdout() @bci=4, line=563 (Interpreted frame) - jdk.test.lib.process.OutputAnalyzer.stdoutShouldNotBeEmpty() @bci=1, line=189 (Interpreted frame) - TestAbortVmOnException.parseOutput(java.lang.Process, java.lang.String) @bci=10, line=75 (Interpreted frame) - TestAbortVmOnException.main(java.lang.String[]) @bci=75, line=56 (Interpreted frame) - java.lang.invoke.LambdaForm$DMH+0x00000003000c0000.invokeStatic(java.lang.Object, java.lang.Object) @bci=10 (Interpreted frame) - java.lang.invoke.LambdaForm$MH+0x0000000300141800.invoke(java.lang.Object, java.lang.Object, java.lang.Object) @bci=33 (Interpreted frame) - java.lang.invoke.Invokers$Holder.invokeExact_MT(java.lang.Object, java.lang.Object, java.lang.Object, java.lang.Object) @bci=20 (Interpreted frame) - jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.lang.Object, java.lang.Object[]) @bci=55, line=154 (Interpreted frame) - jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.lang.Object, java.lang.Object[]) @bci=23, line=103 (Interpreted frame) - java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object[]) @bci=102, line=580 (Interpreted frame) - com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run() @bci=10, line=333 (Interpreted frame) - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1583 (Interpreted frame) - java.lang.Thread.run() @bci=19, line=1570 (Interpreted frame) Maybe it's just really long running and the timeout should be increased. Also, it's running with -Xcomp -XX:TieredStopAtLevel=3 but without a CompileOnly to restrict the number of methods being compiled. ILW = Test times out, intermittent in tier1, no workaround = MLH = P4
27-06-2023
Damon, please have a look.
27-06-2023