debugging 1.4 and execve
phantom at FreeBSD.org.ua
Thu Sep 9 01:02:28 PDT 2004
Hehe. It was funny expirience. The only way (I did not have
much time to look in this issue at the begining) to avoid it --
to avoid calling execve(). java_md.c has function named
SetLibraryPath() IIRC, so you need to debug this function and
find which LD_LIBRARY_PATH it wants to have. Next you need
to exit debuger, set LD_LIBRARY_PATH to exactly this value, and
re-execute debuger. java will look up for new library path, compare
with already set one, and if they are equal (internally it means
what execve() is called already) execution will be continued without
execve(), and as result without any gdb traps.
ps: one more trick, as result of not having of any gdb traps, you'll be
having working 'thread*' command functionality. I do not know about
OpenBSD, but it should be easy to port simple patch for gdb (it
should be in old ports tree) from FreeBSD, which support user threads
listings and switching from inside gdb. Very useful thing while debuging
of heavy threaded applications (like, jvm) ;-)
On Wed, Sep 08, 2004 at 04:54:31PM -0400, Kurt Miller wrote:
> I'm working on the 1.4 port for OpenBSD and need to
> debug the jdk. gdb becomes mostly useless after an
> execve call in java_md.c
> 777 execve(newexec, argv, newenvp);
> Program received signal SIGTRAP, Trace/breakpoint trap.
> Cannot remove breakpoints because program is no longer writable.
> It might be running in another process.
> Further execution is probably impossible.
> 0x019ef160 in ?? ()
> (gdb) bt
> #0 0x03235160 in ?? ()
> Does anyone have a suggestion on how to keep gdb
> working after the execve?
> freebsd-java at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-java-unsubscribe at freebsd.org"
More information about the freebsd-java