-
Bug
-
Resolution: Fixed
-
P4
-
5.0
-
b51
-
x86
-
windows_xp
FULL PRODUCT VERSION :
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
At line 574, the following check is performed. This causes the trace to fail when NATIVE methods or other anomolies occur. In the case of using this
tool, one is probably trying to get all the information possible.
CHECK_JVMTI_ERROR(jvmti, error, "Cannot get method line table");
The code that follows is what should be in place based on the code in the following lines that deal with native frames anyway
// CHECK_JVMTI_ERROR(jvmti, error, "Cannot get method line table");
if ( error == JVMTI_ERROR_NONE ) {
/* Search for line */
lineNumber = lineTable[0].line_number;
for ( i = 1 ; i < lineCount ; i++ ) {
if ( finfo->location < lineTable[i].start_location ) {
break;
}
lineNumber = lineTable[i].line_number;
}
}
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
I was running a Jini based application that used SSL sockets. The trace that was failing now comes out as follows (with some formatting changes for readability).
1: 4083104 bytes 47789 objects 47789 live unknown stack=<empty>
2: 820800 bytes 100 objects 100 live stack:
Ljava/io/BufferedInputStream;.<init>:29
Ljava/io/BufferedInputStream;.<init>:5
Ljavax/crypto/SunJCE_d;.b:184[DashoA12275:0]
Ljavax/crypto/SunJCE_d;.a:19[DashoA12275:0]
Ljavax/crypto/SunJCE_d;.a:23[DashoA12275:0]
Ljavax/crypto/SunJCE_b;.b:13[DashoA12275:0]) nframes=6
It was failing at the javax.crypto lines, which appear to be native code.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
a trace with as much information as is possible should always be given to the user. Any misc data that is not available should be shown as missing.
ACTUAL -
The trace aborts with a non-obvious message
REPRODUCIBILITY :
This bug can be reproduced always.
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
At line 574, the following check is performed. This causes the trace to fail when NATIVE methods or other anomolies occur. In the case of using this
tool, one is probably trying to get all the information possible.
CHECK_JVMTI_ERROR(jvmti, error, "Cannot get method line table");
The code that follows is what should be in place based on the code in the following lines that deal with native frames anyway
// CHECK_JVMTI_ERROR(jvmti, error, "Cannot get method line table");
if ( error == JVMTI_ERROR_NONE ) {
/* Search for line */
lineNumber = lineTable[0].line_number;
for ( i = 1 ; i < lineCount ; i++ ) {
if ( finfo->location < lineTable[i].start_location ) {
break;
}
lineNumber = lineTable[i].line_number;
}
}
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
I was running a Jini based application that used SSL sockets. The trace that was failing now comes out as follows (with some formatting changes for readability).
1: 4083104 bytes 47789 objects 47789 live unknown stack=<empty>
2: 820800 bytes 100 objects 100 live stack:
Ljava/io/BufferedInputStream;.<init>:29
Ljava/io/BufferedInputStream;.<init>:5
Ljavax/crypto/SunJCE_d;.b:184[DashoA12275:0]
Ljavax/crypto/SunJCE_d;.a:19[DashoA12275:0]
Ljavax/crypto/SunJCE_d;.a:23[DashoA12275:0]
Ljavax/crypto/SunJCE_b;.b:13[DashoA12275:0]) nframes=6
It was failing at the javax.crypto lines, which appear to be native code.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
a trace with as much information as is possible should always be given to the user. Any misc data that is not available should be shown as missing.
ACTUAL -
The trace aborts with a non-obvious message
REPRODUCIBILITY :
This bug can be reproduced always.