HP (Hewlett-Packard) 5992-1918 Manuale Utente
Trace through the instructions to see where R25 was loaded with a value. The first place this
happens is at offset 0xcc:
happens is at offset 0xcc:
0xc3ed34ac <jni_GetStaticMethodID()+0xcc>: ldw -0xb0(%sp),%r25
In this instruction, R25 is loaded with the value at sp-0xb0. Use gdb to examine the memory at
sp-0xb0, displaying the output as an address:
sp-0xb0, displaying the output as an address:
(gdb) x /2x $sp-0xb0
0x59a00: 0x00000000 0x00000000
0x59a00: 0x00000000 0x00000000
The value of R25 is 0, and it is carried through to frame 9 leading to the abort.
R25 is loaded with sp-0xb0 in frame 10. The address at b0 bytes off of the sp is the combination
of R24 and R25, which are the third and second parameters passed into
jni_GetStaticMethodID()
of R24 and R25, which are the third and second parameters passed into
jni_GetStaticMethodID()
. Refer to the instruction at offset 0x34 in the listing to see where
sp-b0 is set with these values.
The R25 zero value was passed into jni_GetStaticMethodID() from frame 11, which is the
native C routine Java_StackTrace_dumpCore().
native C routine Java_StackTrace_dumpCore().
Look at selected sections of the C source code (see Section 4.1.3) to find out where that parameter
was set:
was set:
...
Java_StackTrace_dumpCore(JNIEnv *env, jclass class, jint intarg) {
jclass classid;
jmethodID methodid;
...
classid = (*env)->FindClass(env, "java/lang/IntegerX");
...
methodid = (*env)->GetStaticMethodID(env, classid, "toBinaryString",
...
}
jmethodID methodid;
...
classid = (*env)->FindClass(env, "java/lang/IntegerX");
...
methodid = (*env)->GetStaticMethodID(env, classid, "toBinaryString",
...
}
You see the statement where GetStaticMethodID() is called. The second parameter to this
function is classid, which was set previously by calling the FindClass() method, and the
value of classid is zero since the call to FindClass() returned an invalid value. Examining
the code, you see that a literal class name was passed to the FindClass() method. This literal
contains a typographical error. It should read “java/lang/Integer” instead of “java/lang/IntegerX”.
function is classid, which was set previously by calling the FindClass() method, and the
value of classid is zero since the call to FindClass() returned an invalid value. Examining
the code, you see that a literal class name was passed to the FindClass() method. This literal
contains a typographical error. It should read “java/lang/Integer” instead of “java/lang/IntegerX”.
4.8 Summary
Java applications abort and generate core files for a variety of reasons. There are several useful
tools on HP-UX systems that may be helpful in core file analysis. The primary tool used is gdb.
tools on HP-UX systems that may be helpful in core file analysis. The primary tool used is gdb.
There are some environmental issues to take into account to make sure that core files are created
completely. Other files, such as the executable and the shared libraries used by the executable
also should be collected before analyzing the core file.
completely. Other files, such as the executable and the shared libraries used by the executable
also should be collected before analyzing the core file.
In most cases, core file analysis is quite involved and the core file will need to be forwarded to
HP Support for detailed analysis. However, there are times when users can attempt their own
core file analysis. If they are successful, they will speed up the time it takes to resolve their
programming problems.
HP Support for detailed analysis. However, there are times when users can attempt their own
core file analysis. If they are successful, they will speed up the time it takes to resolve their
programming problems.
Many times programs core dump because of bugs in user code. Occasionally, programs core
dump because of bugs in the Java VM. If you suspect the problem is due to a bug in the Java
VM, you may want to research whether the problem has been reported and if there is a
workaround. Useful websites for finding information are the Go Java! website:
dump because of bugs in the Java VM. If you suspect the problem is due to a bug in the Java
VM, you may want to research whether the problem has been reported and if there is a
workaround. Useful websites for finding information are the Go Java! website:
and the Sun bug database:
4.8 Summary
73