JDK-8299494 : Test vmTestbase/nsk/stress/except/except011.java failed: ExceptionInInitializerError: target class not found
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 20,21
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-01-03
  • Updated: 2023-12-12
  • Resolved: 2023-03-21
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 17 JDK 21 JDK 8
11.0.23-oracleFixed 17.0.11-oracleFixed 21 b15Fixed 8u411Fixed
Related Reports
Relates :  
Description
----------messages:(6/301)----------
command: main -Xms50M -Xmx200M nsk.stress.except.except011
reason: User specified action: run main/othervm -Xms50M -Xmx200M nsk.stress.except.except011 
started: Sun Dec 25 22:18:35 UTC 2022
Mode: othervm [/othervm specified]
finished: Sun Dec 25 22:18:38 UTC 2022
elapsed time (seconds): 3.078
----------configuration:(0/0)----------
----------System.out:(20/978)----------
# While printing this message, JVM seems to initiate the output
# stream, so that it will not need more memory to print later,
# when the heap would fail to provide more memory.
# 
# Note, that the test maintains especial static log[] field in
# order to avoid printing when the heap seems exhausted.
# Nevertheless, printing could arise OutOfMemoryError even
# after all the memory allocated by the test is released.
# 
# That problem is caused by the known JDK/HotSpot bugs:
#     4239841 (P1/S5) 1.1: poor garbage collector performance
#     4245060 (P4/S5) poor garbage collector performance
# 
# This message is just intended to work-around that problem.
# If printing should fail even so, the test will try to return
# the exit status 96 instead of 97 to indicate the problem.
# However, the test may fail or even crash on some platforms
# suffering the bug 4239841 or 4245060.
Failure: ExceptionInInitializerError: target class not found
Test failed.
----------System.err:(0/0)----------

Looks like it may have been a OOME during class loading.
Comments
Fix request [11u] I backport this for parity with 11.0.23-oracle. No risk, only a test change. Clean backport. Testing pointless. SAP nightly testing passed.
12-12-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2350 Date: 2023-12-11 08:48:28 +0000
11-12-2023

Fix request [17u] I backport this for parity with 17.0.11-oracle. No risk, only a test change. Clean backport. Testing pointless. SAP nightly testing passed.
07-12-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/2025 Date: 2023-12-06 14:55:43 +0000
06-12-2023

Changeset: bbde2158 Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2023-03-21 13:18:44 +0000 URL: https://git.openjdk.org/jdk/commit/bbde2158d1d11be909292d0c8625211e6cf5359e
21-03-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/13110 Date: 2023-03-21 00:28:51 +0000
21-03-2023

This test is essentially: // eat all the memory try { oops = Class.forName(className); log[messages++] = "Failure: ExceptionInInitializerError failed to throw"; exitCode = 2; catch (ExceptionInInitializerError eiie) // expected catch (ClassNotFoundException) // intermittent failure mode catch (OutOfMemoryError) { Skipped: ExceptionInInitializerError: thrown OutOfMemoryError (pass) } Class.forName() calls JVM_FindClassFromCaller in the VM with a char* for the class name, and the VM gets the OOM allocating the java.lang.String to use for the following loadClass call. So the test always passes with OOM. Sometimes ZGC is able to free up a little bit of memory. In this case, the test gets the unexpected ClassNotFoundException because except011oops.java was never compiled, so there is no except011oops.class to find. Adding @compile except011oops.java would fix this but this test will rarely (never) test what it is expecting to test: that the exception oops may be pre-allocated (which they're not, they're only pre-loaded). We should just remove this test.
20-03-2023