United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-8028412 : AsyncGetCallTrace() is broken on x86 in JDK 7u40

Details
Type:
Bug
Submit Date:
2013-11-15
Status:
Resolved
Updated Date:
2014-01-06
Project Name:
JDK
Resolved Date:
2013-12-05
Component:
hotspot
OS:
solaris,linux
Sub-Component:
svc
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
hs24,hs25
Fixed Versions:
hs25,8 (team)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:

Sub Tasks

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
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);
                                     
2013-11-26
Release team: Approved for fixing
                                     
2013-12-03
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
                                     
2013-11-25
Suggested fix has been verified sucessfully by reporter. I am proceeding with official fix.

                                     
2013-11-26



Hardware and Software, Engineered to Work Together