GetFrameLocation doesn't detect opaque frames

Name: vsR10008 Date: 10/15/2003



JVMTI spec for GetFrameLocation says:

jvmtiError
GetFrameLocation(jvmtiEnv* env,
             jthread thread,
             jint depth,
             jmethodID* method_ptr,
             jlocation* location_ptr)
...
+--------------------------+-----------------------------------------------------+
| Error | Description |
+--------------------------+-----------------------------------------------------+
| JVMTI_ERROR_OPAQUE_FRAME | frame does not correspond to a non-native Java |
| | programming language method. |
+--------------------------+-----------------------------------------------------+

But RI returns JVMTI_ERROR_NONE when invoking this function from
native method (thread == NULL, depth == 0). Note that this invocation
returns correct method ID and method with this ID is native.

To reproduce this bug please run on Solaris the following sh script
(do not forget to change JDK_PATH var):

---- File: runme.sh ---------------------------------------------------
JDK_PATH="/java/re/jdk/1.5.0/latest/binaries/solaris-sparc"

JVMTI_H_PATH="${JDK_PATH}/include"
CC="cc"

echo "...creating a.c"
cat - > a.c <<EOF

#include <stdio.h>
#include "jvmti.h"

static jvmtiEnv *jvmti = NULL;

JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM *jvm, char *options, void *reserved) {
     jvmtiError err;
     jint res;

     res = (*jvm)->GetEnv(jvm, (void **) &jvmti,
           JVMTI_VERSION_1_0);

     if (res != JNI_OK || jvmti == NULL) {
         return JNI_ERR;
     }
     return JNI_OK;
}

JNIEXPORT void JNICALL
Java_a_check(JNIEnv *env, jclass cls) {
     jvmtiError err;

     jmethodID mid;
     jlocation loc;
     jboolean nat;

     err = (*jvmti)->GetFrameLocation(jvmti, NULL, 0, &mid, &loc);
     if (err != JVMTI_ERROR_OPAQUE_FRAME) {
         printf("(GetFrameLocation) Error expected: %d, got: %d\n",
                 JVMTI_ERROR_OPAQUE_FRAME, err);
     }
     err = (*jvmti)->IsMethodNative(jvmti, mid, &nat);
     if (nat == JNI_TRUE) {
         printf("Method is NATIVE\n");
     }
}

EOF

echo "...creating liba.so"

${CC} -G -KPIC -o liba.so -I${JDK_PATH}/include -I${JDK_PATH}/include/solaris -I${JVMTI_H_PATH} a.c

echo "...creating a.java"

cat - > a.java <<EOF
public class a {
     native static void check();
     public static void main(String args[]) {
         System.loadLibrary("a");
         check();
     }
}

EOF

echo "...creating a.class"

${JDK_PATH}/bin/javac -d . a.java

echo "...running a.class"
LD_LIBRARY_PATH=. CLASSPATH=. ${JDK_PATH}/bin/java -showversion -agentlib:a a
-----------------------------------------------------------------------

Running on b23, execution log is as follows:

----------------------------------------------------------------------
bash-2.03$ sh runme.sh
...creating a.c
...creating liba.so
...creating a.java
...creating a.class
...running a.class
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b23)
Java HotSpot(TM) Client VM (build 1.5.0-beta-b23, mixed mode)

(GetFrameLocation) Error expected: 32, got: 0
Method is NATIVE
----------------------------------------------------------------------

This bug is reproducible on builds 19-23 and affects JCK JVMTI test:
vm/jvmti/GetFrameLocation/gfrl001/gfrl00102/gfrl00102.html

======================================================================
 

Robert wrote:
------------------------------------------------------------------------------
I think this is a spec bug. You need to be able to get the method name of a native method. I will change:

   location_ptr param of GetFrameLocation -- add "Is set to -1 if frame is native"
   Remove JVMTI_ERROR_OPAQUE_FRAME from GetFrameLocation.
   jvmtiFrameInfo.location -- add "-1 if frame is native"
----------------------------------------------------------------------------


Robert Field is working on changing the spec. So assigning this to
test to fix the test case.


###@###.### 2003-11-07

Name: vsR10008 Date: 11/10/2003


Test vm/jvmti/GetFrameLocation/gfrl001/gfrl00102/gfrl00102.html
should be fixed due to the latest JVMTI spec change (see 4949788).
======================================================================