JDK-8169941 : CodeBlob::is_frame_complete_at() does not honor CodeOffsets::frame_never_safe
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7u121,8u112,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-11-18
  • Updated: 2016-12-22
  • Resolved: 2016-11-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 9
9 b150Fixed
Related Reports
Blocks :  
JDK-8168445 - make pd_get_top_frame_for_profiling more robust
Relates :  
JDK-8170152 - WhiteBox testing of pd_get_top_frame_for_profiling
Relates :  
JDK-6250767 - segv running AsyncGetCallTrace
Description
Way back in JDK-6250767, CodeBlob::is_frame_complete_at() and CodeOffsets::frame_never_safe were introduced to support AsyncGetCallTrace.  We still rely on this for pd_get_top_frame_for_profiling and friends.  However, it appears this has been broken forever, and that even in the JDK-6250767 changeset, CodeBlob::is_frame_complete_at() would return true if the frame complete offset was CodeOffsets::frame_never_safe (-1), making the value effectively mean "always safe".
Comments
Hi Dean, yes, that sounds like a good way to test for these kind of problems. But wouldn't it be sufficient to have a Whitebox method that walks the current stack on request? I think it would be good if you could file a new testbug/enhancement to keep track of this.
21-11-2016
Hi [~thartmann], one method I have used to test changes like this in a determiniistic way is to simulate an asynchronous profiling call by inserting a special instruction that will always cause a SEGV or illegal instruction trap, then in the signal handler, call pd_get_top_frame_for_profiling and see if it can walk the stop few frames. I used a temporary change that I removed before pushing, but we could leave it in as a whitebox feature. For performance it could be enabled in debug builds only, and after the first successful stack walk, we could rewrite the instruction to a NOP.
18-11-2016
Webrev: http://cr.openjdk.java.net/~thartmann/8169941/webrev.00/
18-11-2016
ILW = frame incorrectly marked as "always safe" may cause crash during profiling, rare, no workaround = MMH = P3
18-11-2016