Debugging Java and C++ code

[mathieu]

Hello there,

I have been reading the document from :
http://www-128.ibm.com/developerworks/java/library/j-jnidebug/index.html

And I am trying to reproduce this. Unfortunately it does not seems to
work for me. Here are the different console I have:

1.
$ java -Xdebug -Xnoagent -Djava.compiler=none
-Xrunjdwp:transport=dt_socket,server=y,suspend=y MyTest
Listening for transport dt_socket at address: 45515

I then open a new window:

2.
$ jdb -attach 45515
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...VM Started: No frames on the current call stack

main[1] stop at MyTest:18
Deferring breakpoint MyTest:18.
It will be set after the class is loaded.
main[1] run

Set deferred breakpoint MyTest:18

Breakpoint hit: "thread=main", MyTest.main(), line=18 bci=0

main[1]

so I believe the c++ library should be loaded by now. Therefore I start
gdb:

$ ps -ef | grep jdb
mathieu 22850 22760 0 11:26 pts/10 00:00:00 jdb -attach 45515
mathieu 22875 22785 0 11:27 pts/12 00:00:00 grep jdb
$ gdb


GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i486-linux-gnu".
(gdb) attach 22850
Attaching to process 22850
Reading symbols from /usr/lib/j2sdk1.5-sun/bin/jdb...(no debugging
symbols found)...done.
Using host libthread_db library "/lib/tls/libthread_db.so.1".
Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols
found)...done.
[Thread debugging using libthread_db enabled]
[New Thread -1478199616 (LWP 22850)]
[New Thread -1751094352 (LWP 22861)]
[New Thread -1750570064 (LWP 22860)]
[New Thread -1750045776 (LWP 22859)]
[New Thread -1739064400 (LWP 22857)]
[New Thread -1738540112 (LWP 22856)]
[New Thread -1736578128 (LWP 22855)]
[New Thread -1736053840 (LWP 22854)]
[New Thread -1735238736 (LWP 22853)]
[New Thread -1734714448 (LWP 22852)]
[New Thread -1734190160 (LWP 22851)]
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/tls/libdl.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libdl.so.2
Reading symbols from /lib/tls/libc.so.6...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from
/usr/lib/j2sdk1.5-sun/jre/lib/i386/client/libjvm.so...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib/j2sdk1.5-sun/jre/lib/i386/client/libjvm.so
Reading symbols from /lib/tls/libm.so.6...
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libm.so.6
Reading symbols from
/usr/lib/j2sdk1.5-sun/jre/lib/i386/native_threads/libhpi.so...(no
debugging symbols found)...done.
Loaded symbols for
/usr/lib/j2sdk1.5-sun/jre/lib/i386/native_threads/libhpi.so
Reading symbols from /lib/tls/libnsl.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libnsl.so.1
Reading symbols from /lib/tls/libnss_compat.so.2...(no debugging
symbols found)...done.
Loaded symbols for /lib/tls/libnss_compat.so.2
Reading symbols from /lib/tls/libnss_nis.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libnss_nis.so.2
Reading symbols from /lib/tls/libnss_files.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libnss_files.so.2
Reading symbols from /usr/lib/j2sdk1.5-sun/jre/lib/i386/libverify.so...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/j2sdk1.5-sun/jre/lib/i386/libverify.so
Reading symbols from
/usr/lib/j2sdk1.5-sun/jre/lib/i386/libjava.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/j2sdk1.5-sun/jre/lib/i386/libjava.so
Reading symbols from /usr/lib/j2sdk1.5-sun/jre/lib/i386/libzip.so...(no
debugging symbols found)...done.
Loaded symbols for /usr/lib/j2sdk1.5-sun/jre/lib/i386/libzip.so
Reading symbols from /usr/lib/j2sdk1.5-sun/jre/lib/i386/libnet.so...(no
debugging symbols found)...done.
Loaded symbols for /usr/lib/j2sdk1.5-sun/jre/lib/i386/libnet.so
Reading symbols from /usr/lib/libnss_db.so.2...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libnss_db.so.2
Reading symbols from /usr/lib/libdb-4.3.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libdb-4.3.so

(no debugging symbols found)
0xa7f89401 in __read_nocancel () from /lib/tls/libpthread.so.0
(gdb)

The weird thing is that none of my libraries seems to be loaded. Is
there something I am missing here ?

Thanks for your help
Mathieu

 

[Gordon Beaton]

I have been reading the document from :
http://www-128.ibm.com/developerworks/java/library/j-jnidebug/index.html
[...]

The weird thing is that none of my libraries seems to be loaded. Is
there something I am missing here ?

Look in /proc/<pid>/maps to verify whether the library is loaded.

You might also want to specify -ggdb when you compile (not just -g),
get more debugging information into the library.

When I need to debug native code, I find it easier to (temporarily)
statically link the native library together with a JVM launcher, and
use RegisterNatives to attach the native methods to their class. This
lets me start the program from gdb and set breakpoints directly in the
native methods. I believe this is similar to the invocation method
mentioned in the article, but without jdb (I didn't look that
closely).

/gordon

 

[mathieu]

I have been reading the document from :
http://www-128.ibm.com/developerworks/java/library/j-jnidebug/index.html
[...]

The weird thing is that none of my libraries seems to be loaded. Is
there something I am missing here ?

[...]
When I need to debug native code, I find it easier to (temporarily)
statically link the native library together with a JVM launcher, and
use RegisterNatives to attach the native methods to their class. This
lets me start the program from gdb and set breakpoints directly in the
native methods. I believe this is similar to the invocation method
mentioned in the article, but without jdb (I didn't look that
closely).

I'll have to try that next. Just for fun I tried recompiling the whole
thing with gcj instead of Sun Java and I cannot reproduce the issue
anymore...

-M