debugging 1.4 and execve
Kurt Miller
truk at optonline.net
Thu Sep 9 08:31:31 PDT 2004
From: "Alexey Zelkin" <phantom at FreeBSD.org.ua>
> 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.
Thanks, it did the trick.
> 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) ;-)
Yea, not having gdb thread* in OpenBSD has been an issue for me in
the past. I'll take a look at porting freebsd-uthread.c over.
-Kurt
More information about the freebsd-java
mailing list