JDK-8210754 : print_location is not reliable enough (printing register info)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-09-14
  • Updated: 2019-05-28
  • Resolved: 2018-10-04
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 12
11.0.2Fixed 12 b15Fixed
Related Reports
Relates :  
JDK-8147512 - Cleanups and improvements for print_location
Relates :  
JDK-8219459 - oopDesc::is_valid() is broken
Description
I had contributed some improvements for the error reporting step "printing register info" with JDK-8207342.
But there are still parts which crash too easily. Oop and klass checks should get improved.
I have seen
"[error occurred during error reporting (printing register info), id 0xe0000000, Internal Error (/openjdk/jdk/src/hotspot/share/oops/klass.inline.hpp:63)]"
when using -XX:+CrashGCForDumpingJavaThread with recent jdk12.

"[error occurred during error reporting (printing register info)" can also be found in many hs_err files in the internet. This change is supposed to help people to investigate the root cause of crashes by providing the register info much more reliably.
Comments
Please add an appropriate noreg label.
18-10-2018
Fix Request SAP wants to use this change in jdk11u to get better hs_err files for investigation of crashes in the LTS release. I believe this would be helpful for anybody else supporting jdk11u, too, so I prefer to push it to jdk11u instead of sapmachine only. Fix has been tested in the official jdk12 and in our internal jdk11u tests. New code is only used during error reporting, so I think the risk is low. Applies almost cleanly. Only one function needs to be moved due to JDK-8209645: "Split ClassLoaderData and ClassLoaderDataGraph into separate files". In addition, 1 small adaptation (one line) is needed for JDK-8207779: "Method::is_valid_method() compares 'this' with NULL" which has changed the signature. No real functional change needed. After running through our internal testing, backport should be safe.
15-10-2018