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