john cuthbertson - Sun Microsystems
John.Cuthbertson at Sun.COM
Wed Sep 16 17:05:58 PDT 2009
As Xiaobin says frames 2 to 8 are most likely in dynamically generated
code. Since you have broken in JNI code for the native method
FileInputStream::initIDs frame #2 is likely to be a native call wrapper
or the native method entry code in the interpreter.
If you look in debug.cpp there are a number of routines that you can use
command line calls to call within your gdb session:
> p findpc(0xb4ff25aa)
which should print a code blob. You can then use the blob routine to
determine the type of code blob. If the code blob is an nmethod (the
structure used to hold JIT generated code) then you use the printnm routine:
> p printnm(0xb4ff25aa)
If the specified address is not in a JIT compiled method then this
routine just returns quietly with no output.
The zero PC at frame 9 tells me that for some reason gdb was unable to
successfully unwind from frame 8.
- John Cuthbertson
On 09/16/09 10:52, Xiaobin Lu wrote:
> I am not sure about why #9's address is 0x000000, but most likely #2 -
> #8 are JIT compiled code. You should be able to find out what method
> these address points to by specifying -XX:+UnlockDiagnosticVMOptions
> -XX:+PrintNMethods as part of the flags to run your application.
> On 09/16/09 08:27, ericjoh wrote:
>> I build the JDK with
>> $ DEBUG_BINARIES=true DEBUG_CLASSFILES=true OPTIMIZATION_LEVEL=NONE
>> make ...
>> When I set a breakpoint (and step one level) I see
>> (gdb) bt
>> #0 jni_GetFieldID (env=0x804fd10, clazz=0x173aa0, name=0x1ae519
>> "fd", sig=0x1ae500 "Ljava/io/FileDescriptor;")
>> #1 0x00198ee8 in Java_java_io_FileInputStream_initIDs
>> (env=0x804fd10, fdClass=0x173aa0) at
>> #2 0xb4ff25aa in ?? ()
>> #3 0x0804fd10 in ?? ()
>> #4 0x00173aa0 in ?? ()
>> #5 0x00173a78 in ?? ()
>> #6 0x91657a60 in ?? ()
>> #7 0x00173aa4 in ?? ()
>> #8 0x91658f30 in ?? ()
>> #9 0x00000000 in ?? ()
>> Why can't I see the code at #2, ..., #9 ?
>> Eric J.
More information about the hotspot-dev