JDK-8304931 : vm/concepts/methods/methods001/methods00101m1/methods00101m1 failures with already pending exception
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 21
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2023-03-26
  • Updated: 2023-06-29
  • Resolved: 2023-03-27
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
21 b16Fixed
Related Reports
Relates :  
JDK-8304069 - ClassFileParser has ad-hoc hashtables
Description
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S24665/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/19ada292-095c-4a96-88e4-8469ef3802b1/runs/bbbae971-d40c-4e18-8cd5-ce41dd8a279d/workspace/open/src/hotspot/share/utilities/exceptions.cpp:366), pid=2573427, tid=2573910
#  assert(incoming_exception.is_null()) failed: Pending exception while throwing java/lang/ClassFormatError Duplicate method name "proc2" with signature "(I)V" in class file javasoft/sqe/tests/vm/concepts/methods/methods001/methods00101m1/methods00101m11n
#
# JRE version: Java(TM) SE Runtime Environment (21.0+16) (fastdebug build 21-ea+16-LTS-1267)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 21-ea+16-LTS-1267, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, parallel gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xd43241]  Exceptions::new_exception(JavaThread*, Symbol*, char const*, Handle, Handle, Handle, Exceptions::ExceptionMsgToUtf8Mode)+0x221

This appears to be caused by JDK-8304069. That change moved some calls to classfile_parse_error from the end of the calling function into the loop where the detection is occurring. But the calls still pass THREAD as the final argument. That will record a pending exception, but not terminate the loop. So if there are multiple problems in the class file, instead of throwing an exception reporting the first one, we get this pending exception crash. I think the in-loop calls to classfile_parse_error should be be using CHECK as the last argument rather than THREAD.
Comments
The fix for this bug is integrated in jdk-21+16-1290.
28-03-2023
Changeset: 6aec6f3a Author: Matias Saavedra Silva <matsaave@openjdk.org> Date: 2023-03-27 22:12:36 +0000 URL: https://git.openjdk.org/jdk/commit/6aec6f3a842ead30b26cd31dc57a2ab268f67875
27-03-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/13195 Date: 2023-03-27 19:51:27 +0000
27-03-2023
Since this is a regression, I'm bumping it from P3 -> P2. We normally start regressions at P2, but the triage team may adjust it back down as part of their analysis.
27-03-2023
I agree with the analysis. The old code would detect an error and break the loop, then call classfile_parse_error with THREAD, then return. The new code calls classfile_parse_error in place in the loop and will just continue!
26-03-2023