JDK-8066799 : hs_err can contain incomplete stack trace
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u60
  • Priority: P5
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: x86
  • Submitted: 2014-12-05
  • Updated: 2015-02-02
  • Resolved: 2015-01-05
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 8
8u60Fixed
Related Reports
Relates :  
JDK-8072066 - Need test to cover fix hs_err can contain incomplete stack trace
Relates :  
JDK-8068336 - Refactor native stack printing from vmError.cpp to debug.cpp to make it available in gdb as well
Description
On x86, if %RBP does not contain the base pointer (becasue the compile has used that register for something else), the stack trace printed in an hs_err file can be incorrect (e.g., it can contain a call, as shown in the attached hs_err file, readDerbyUTF.hs_err.log). Fixing this issue can help debugging failures.
Comments
Fixed by 8u60 backport of JDK-8058345.
05-01-2015
A backport of the changes by JDK-8058345 to 8u60 will indeed fix this issue. I attached an hs_err file (hs_err_pi12966.log) that was produced with JDK 8u40 with patched with the backport. The file contains the stack trace for the method where the failure appears; the failure appears due an other issue, XMM register state not being preserved by the kernel. The failing method (spec.jbb.CustomerReportTransaction.process) stores in %rbp something else than the frame pointer, see first couple of instructions of the method below: 0x2aaaac32dc40: mov 0x8(%rsi),%r10d 0x2aaaac32dc44: shl $0x3,%r10 0x2aaaac32dc48: cmp %r10,%rax 0x2aaaac32dc4b: jne 0x2aaaab29af40 0x2aaaac32dc51: nop 0x2aaaac32dc52: nop 0x2aaaac32dc53: nop 0x2aaaac32dc54: nop 0x2aaaac32dc55: nop 0x2aaaac32dc56: nop 0x2aaaac32dc57: nop 0x2aaaac32dc58: nop 0x2aaaac32dc59: nop 0x2aaaac32dc5a: nop 0x2aaaac32dc5b: nop 0x2aaaac32dc5c: nop 0x2aaaac32dc5d: nop 0x2aaaac32dc5e: nop 0x2aaaac32dc5f: nop 0x2aaaac32dc60: mov %eax,-0x16000(%rsp) 0x2aaaac32dc67: push %rbp 0x2aaaac32dc68: sub $0x80,%rsp 0x2aaaac32dc6f: mov %rsi,%r10 0x2aaaac32dc72: mov $0x6cc6c5980,%r11 0x2aaaac32dc7c: mov 0x84(%r11),%ebp As JDK 9 contains this change, it is indeed unaffected by this problem.
16-12-2014
[~vlivanov] Yes, you are right. Thank you for noticing that and also for adding the correct affected version. I did some investigation and it seems that the changes by JDK-8058345 would fix this issue (but I have to still verify that). So a simple backport of JDK-8058345 into 8u60 might solve the issue. I think 9 is unaffected (but have to verify that as well).
08-12-2014