Date: Thu, 09 Sep 2004 11:29:34 -0400 From: Kurt Miller <truk@optonline.net> To: Alexey Zelkin <phantom@FreeBSD.org.ua> Cc: freebsd-java@freebsd.org Subject: Re: debugging 1.4 and execve Message-ID: <06c101c49681$cf920f60$1d0110ac@focus> References: <033d01c495e6$09de3230$1d0110ac@focus> <20040909080415.GA49910@phantom.cris.net>
next in thread | previous in thread | raw e-mail | index | archive | help
From: "Alexey Zelkin" <phantom@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?06c101c49681$cf920f60$1d0110ac>