Date: Tue, 20 Nov 2001 18:39:06 -0800 From: Joe Kelsey <joe@zircon.seattle.wa.us> To: freebsd-java@freebsd.org, Bill Huey <billh@gnuppy.monkey.org> Subject: Re: Plugin fails in sysThreadBootstrap Message-ID: <15355.5066.999963.87971@zircon.zircon.seattle.wa.us> In-Reply-To: <20011120160821.A1049@gnuppy> References: <15354.52288.892293.990664@zircon.zircon.seattle.wa.us> <20011120160821.A1049@gnuppy>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Huey writes:
> On Tue, Nov 20, 2001 at 01:33:52PM -0800, Joe Kelsey wrote:
> > I have been debugging the plugin today. I have managed to step through
> > InitializeJavaVM function up to the call to sysThreadBootstrap(), line
> > 666 in javai.c. For some reason, gdb does not want to step into that
> > function call, I suspect because I have somehow loaded a non-debugging
> > version of libhpi. How to I get a version of libhpi with symbols so I
> > can step further into the java_vm startup?
> If you figure this out, I'd like to know how you got it to work.
Here is a little tutorial on how to debug the OJI plugin, along with the
answer to Bill's question, which is how do you set a breakpoint in a
function loaded via the dlopen() interface.
1) Define environment variables for the plugin:
JAVA_VM_WAIT=true
JAVA_PLUGIN_TRACE=true
JAVA_PLUGIN_DEBUG=true
THREADS_FLAG=green
JAVA_VM_WAIT will make the plugin pause for a short while in java_vm to
allow you to attach to the process with gdb.
2) Open a terminal window and get a gdb command line ready:
gdb /usr/local/jdk1.3.1/bin/i386/green_threads/java_vm
Leave the terminal poised at the space after java_vm so you can easily
enter the pid and launch gdb in step 5.
3) Start mozilla
mozilla&
start in the background so you can use ps to find the pid of java_vm.
4) Visit /usr/local/jdk1.3.1/jre/ControlPanel.html
This will start the plugin. Wait for the message:
131 After exec, before startup:Going to sleep for debugging...
Then type ps. Remember the pid of java_vm.
ps
PID TT STAT TIME COMMAND
456 p0 Ss 0:00.78 ksh (ksh93)
8588 p0 IN 0:00.02 /bin/sh ./run-mozilla.sh ./mozilla-bin
8610 p0 SN 0:11.28 ./mozilla-bin
8611 p0 ZN 0:00.00 (netstat)
8612 p0 SN 0:00.10 java_vm -t
8613 p0 R+ 0:00.00 ps
7364 p2 Is+ 0:00.06 ksh (ksh93)
5) Go to the other terminal window and type the pid of java_vm followed
by <RET> to launch gdb. You have about 30 seconds to do this. Don't
be too slow!
6) Set a breakpoint in InitializeHPI. Continue the process. Step
through InitializeHPI (actually use next to step through to prevent
too much superfluous stuff.) After line 58:
(gdb) next
58 hpi_handle = dlopen(buf, RTLD_NOW);
(gdb) next
59 if (hpi_handle == NULL) {
(gdb) shared
Symbols already loaded for /usr/local/jdk1.3.1/jre/lib/i386/client/libjvm_g.so
Symbols already loaded for /usr/local/jdk1.3.1/jre/lib/i386/libjava_g.so
...
Symbols already loaded for /usr/X11R6/lib/libXThrStub.so.6
Reading symbols from /usr/local/jdk1.3.1/jre/lib/i386/green_threads/libhpi_g.so...done.
Symbols already loaded for /usr/libexec/ld-elf.so.1
(gdb) b sysThreadBootstrap
Breakpoint 2 at 0x286f902e: file ../../../../src/solaris/hpi/src/system_md.c, line 43.
(gdb) c
As you can see, the shared command will make gdb re-read the shared
symbols. Since we just added libhpi_g.so to the mix, those symbols will
be added.
Ultimately, the problem appears to be green_sigprocmask(), which is not
loading libc.so correctly. The function was written assuming that
RTLD_NEXT is undefined in FreeBSD. However, it has been implemented,
but does not work the same as solaris, apparantly. I think we need to
modify this use to at least open libc.so if it is not loaded.
So, Bill, the answer to your question is to use the gdb shared command
to re-read the symbol tables after manually loading any shared
libraries, such as hpi.
/Joe
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15355.5066.999963.87971>