JDK-8214904 : Test8004741.java failed due to "Too few ThreadDeath hits; expected at least 6 but saw only 5"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2018-12-05
  • Updated: 2022-06-27
  • Resolved: 2019-11-15
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 11 JDK 13 JDK 14
11.0.7-oracleFixed 13.0.4Fixed 14 b24Fixed
Related Reports
Relates :  
JDK-8235801 - compiler/c2/Test8004741.java failed due to "Error: test method didn't get compiled"
Sub Tasks
JDK-8224870 :  
Problemlist compiler/c2/Test8004741.java until JDK-8214904 is fixed - Resolved
Description
The following test failed in the jdk/jdk CI:

    compiler/c2/Test8004741.java

Here's a snippet of the log file:

#section:main
----------messages:(4/572)----------
command: main -Xmx128m -Xbatch -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressCompiledExceptionHandlers -XX:+SafepointALot -XX:GuaranteedSafepointInterval=100 compiler.c2.Test8004741
reason: User specified action: run main/othervm -Xmx128m -Xbatch -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressCompiledExceptionHandlers -XX:+SafepointALot -XX:GuaranteedSafepointInterval=100 compiler.c2.Test8004741 
Mode: othervm [/othervm specified]
elapsed time (seconds): 7.852
----------configuration:(0/0)----------
----------System.out:(33/664)----------
Saw expected NegativeArraySizeException #1
Saw expected NegativeArraySizeException #2
thread running
stopping thread
test got ThreadDeath
thread running
stopping thread
test got ThreadDeath
thread running
stopping thread
thread running
stopping thread
thread running
stopping thread
test got ThreadDeath
thread running
stopping thread
thread running
stopping thread
thread running
stopping thread
thread running
stopping thread
thread running
stopping thread
thread running
stopping thread
test got ThreadDeath
thread running
stopping thread
test got ThreadDeath
Too few ThreadDeath hits; expected at least 6 but saw only 5
FAILED
----------System.err:(0/0)----------
----------rerun:(48/4708)*----------
Comments
Fix request (13u) I would like to downport this. Applies cleanly.
03-06-2020
Fix request (11u) I would like to downport this for parity with 11.0.7-oracle. Applies clean except for trivial resolve in ProblemList.txt: the test was never problemlisted in 11.
02-12-2019
URL: https://hg.openjdk.java.net/jdk/jdk/rev/8e7f29b1ad4a User: iignatyev Date: 2019-11-15 22:25:01 +0000
15-11-2019
actually, there is no race b/c there is happen-before edge b/w all actions in Test8004741::run (including updates of passed) and Thread.join (L142) in threadTest. so there is no need to use AtomicInteger.
15-11-2019
there is also a race on 'passed' field, j.u.c.AtomicInteger should be used here
31-01-2019
Another bug: the error message says "at least" but the test is: if (passed > N/2) { rather than if (passed >= N/2) {
06-12-2018
Thank you [~dholmes] for the points. Adding testbug for now (also need to check needs of the test details as in old JDK-8006500 comments) Also found some failures in history as - "Too few ThreadDeath hits; expected at least 6 but saw only 6"
06-12-2018
The test is flawed and subject to intermittent failures. As per the comments in the test: * Catches and rethrows all exceptions; in the case of ThreadDeath, increments passed. * Note that passed is incremented here because this is the exception handler with * the smallest scope; we only want to declare success in the case where it is highly * likely that the test condition * (exception in 2-d array alloc interrupted by ThreadDeath) * actually occurs. So the hope is that the t.stop() hits inside the test() method, but it could also hit outside the test method in the run() method. The test knows this and actually considers the test successful if at least half ot the threads (12 started) get the exception where expected, else it fails. So here we only had 5 hits when we assumed a minimum of 6 so the test reported failure. But this means the test will fail intermittently.
06-12-2018