JDK-8216977 : ShowHiddenFrames use in java_lang_StackTraceElement::fill_in appears broken
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11,13,14
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-01-14
  • Updated: 2020-06-01
  • Resolved: 2019-08-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 11 JDK 13 JDK 14
11.0.6Fixed 13.0.4Fixed 14 b13Fixed
Related Reports
Relates :  
Description
Came up during code review for JDK-8216308

https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-January/036217.html

    Symbol* source = Backtrace::get_source_file_name(holder, version);
    if (ShowHiddenFrames && source == NULL)
      source = vmSymbols::unknown_class_name();
    oop filename = StringTable::intern(source, CHECK);
    java_lang_StackTraceElement::set_fileName(element(), filename);

There's no obvious connection between the use of ShowHiddenFrames and whether the frame for the current method is hidden.
Comments
Fix Request (13u) This fixes the leftover from JDK-8216308 work, improves stack trace usability, and lines it up with spec. Patch applies cleanly to 13u. Patch passes tier1 and new test.
26-05-2020

Fix Request (11u) This fixes the leftover from JDK-8216308 work, improves stack trace usability, and lines it up with spec. Patch does not apply cleanly to 11u, because there is one chunk missing due to JDK-8220623 added later. Updated patch passes tier1 and new test. 11u RFR: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-September/001866.html
11-09-2019

URL: https://hg.openjdk.java.net/jdk/jdk/rev/8ec5ad4f5cc3 User: coleenp Date: 2019-08-29 13:30:58 +0000
29-08-2019

The special casing for BCI doesn't help one find any line number for debugging though.
29-08-2019

Setting null filename is good since it's unavailable. I believe special casing the hidden frame to include BCI in the line number to aid debugging. Hidden frames are filtered by default unless -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames are specified.
28-08-2019

* @param fileName the name of the file containing the execution point * represented by the stack trace element, or {@code null} if * this information is unavailable * @param lineNumber the line number of the source line containing the * execution point represented by this stack trace element, or * a negative number if this information is unavailable. A value * of -2 indicates that the method containing the execution point * is a native method "Unknown" and 1000002 are contrary to the specification for these values in java/lang/StackTraceElement.
28-08-2019

I don't know why there's special source file name, bci code for hidden frames and why this: at HiddenFrameTest$$Lambda$1/0x0000000800bb5040.someMethod(<Unknown>:1000002) is preferable to this: at HiddenFrameTest$$Lambda$1/0x0000000800bb5040.someMethod(Unknown Source) Seems like a the special case was added at some time in the past when printStackTrace didn't handle null source.
28-08-2019

> I'm also very unclear about how the redefinition case is currently > handled. It seems that we will normally intern NULL (and presumably > get a NULL or empty-string oop?) unless ShowHiddenFrames is set, in > which case we use the unknown_class_name() - regardless of whether the > frame is actually hidden or not! This seems broken to me. (Separate > bug to fix that is okay if it is indeed broken.) This looks like a bug, but I'm not sure what ShowHiddenFrames is supposed to do here, or how it got there. I think if Aleksey removed that with this patch it would be fine with me.
27-08-2019