JDK-8028412 : AsyncGetCallTrace() is broken on x86 in JDK 7u40
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: hs24,hs25
  • Priority: P2
  • Status: Closed
  • Resolution: Other
  • OS: linux,solaris
  • CPU: x86
  • Submitted: 2013-11-15
  • Updated: 2015-02-10
  • Resolved: 2015-02-10
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 7 JDK 8 JDK 9 Other
7u60Fixed 8Fixed 9Fixed hs25Fixed
Related Reports
Relates :  
JDK-8029796 - Need test to cover JDK-8028412
Relates :  
JDK-8005849 - JEP 167: Event-Based JVM Tracing
Description
Via e-mail from Marty:

When we updated our Java 1.7.0 to

  raman[MA] 45% jdk1.7.0_45/bin/java -version
  java version "1.7.0_45"
  Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
  Java HotSpot(TM) Server VM (build 24.45-b08, mixed mode)

Our tests of a mixed Java/C++ code started failing.  We have tracked it down to
AsyncGetCallTrace in the new J170 version which does not correctly unwind the
Java callstack.

Our previous Java 1.7.0 was:
  raman[MA] 48% jdk1.7.0_40-ea-b30/bin/java -version
  java version "1.7.0_40-ea"
  Java(TM) SE Runtime Environment (build 1.7.0_40-ea-b30)
  Java HotSpot(TM) Server VM (build 24.0-b49, mixed mode)


When our test code was in the task that called from Java to native code, and then
back to Java, with Java 1.6.0, and previous Java 1.7.0 versions we get:

   jsynprog.javafunc(int) + 0x00000036, line 223 in "jsynprog.java"
   JNIEnv_::CallStaticIntMethod(_jclass*,_jmethodID*,...) + 0x00000016, line 1428 in "jni.h"
   Java_jsynprog_JavaCJava + 0x0000007B, line 105 in "cloop.cc"
   jsynprog.JavaCJava(int) <Java native method>
   jsynprog.main(java.lang.String[]) + 0x00000161, line 117 in "jsynprog.java"

In the latest Java 1.7.0_45, we only get one frame:

   jsynprog.javafunc(int) + 0x0000003A, line 222 in "jsynprog.java"


We are currently also testing Java 1.8.0:
  raman[MA] 47% jdk1.8.0_ea-b80/bin/java -version
  java version "1.8.0-ea"
  Java(TM) SE Runtime Environment (build 1.8.0-ea-b80)
  Java HotSpot(TM) Server VM (build 25.0-b21, mixed mode)

and it is working fine.  We tried with the latest available build,
and the same bug is now there, too.  (I don't have the version number for it,
but I've asked for it.)

This bug is a show-stopper for us: it breaks our support for mixed Java/C++ codes.
It is on intel-S2 and intel-Linux, but not sparc-S2.

What should I do?

    Thanks,
        Marty
Comments
Removing invalid multiple values for fixVersions.
10-02-2015
Release team: Approved for fixing
03-12-2013
Code change located to cpu/x86/vm/frame_x86.cpp: diff --git a/src/cpu/x86/vm/frame_x86.cpp b/src/cpu/x86/vm/frame_x86.cpp --- a/src/cpu/x86/vm/frame_x86.cpp +++ b/src/cpu/x86/vm/frame_x86.cpp @@ -94,13 +94,6 @@ // other generic buffer blobs are more problematic so we just assume they are // ok. adapter blobs never have a frame complete and are never ok. - // check for a valid frame_size, otherwise we are unlikely to get a valid sender_pc - - if (!Interpreter::contains(_pc) && _cb->frame_size() <= 0) { - //assert(0, "Invalid frame_size"); - return false; - } - if (!_cb->is_frame_complete_at(_pc)) { if (_cb->is_nmethod() || _cb->is_adapter_blob() || _cb->is_runtime_stub()) { return false; @@ -144,6 +137,11 @@ // must be some sort of compiled/runtime frame // fp does not have to be safe (although it could be check for c1?) + // check for a valid frame_size, otherwise we are unlikely to get a valid sender_pc + if (_cb->frame_size() <= 0) { + return false; + } + sender_sp = _unextended_sp + _cb->frame_size(); // On Intel the return_address is always the word on the stack sender_pc = (address) *(sender_sp-1);
26-11-2013
Suggested fix has been verified sucessfully by reporter. I am proceeding with official fix.
26-11-2013
I = MEDIUM L = MEDIUM W = HIGH Stackwalking code in frame.safe_for_sender(thread) has been made a little too robust, there is a check for _cb->frame_size() <= 0 which is located too early. This stops stackwalking over StubRoutines(1) frames. Fix in progress. /Markus
25-11-2013