From owner-freebsd-java@FreeBSD.ORG Thu Sep 9 15:31:31 2004 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77F0516A4CE for ; Thu, 9 Sep 2004 15:31:31 +0000 (GMT) Received: from mta3.srv.hcvlny.cv.net (mta3.srv.hcvlny.cv.net [167.206.5.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42B4F43D1D for ; Thu, 9 Sep 2004 15:31:31 +0000 (GMT) (envelope-from truk@optonline.net) Received: from focus (ool-182e24b7.dyn.optonline.net [24.46.36.183]) by mta3.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with SMTP id <0I3S008JX5P5IE@mta3.srv.hcvlny.cv.net> for freebsd-java@freebsd.org; Thu, 09 Sep 2004 11:29:29 -0400 (EDT) Date: Thu, 09 Sep 2004 11:29:34 -0400 From: Kurt Miller To: Alexey Zelkin Message-id: <06c101c49681$cf920f60$1d0110ac@focus> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <033d01c495e6$09de3230$1d0110ac@focus> <20040909080415.GA49910@phantom.cris.net> cc: freebsd-java@freebsd.org Subject: Re: debugging 1.4 and execve X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 15:31:31 -0000 From: "Alexey Zelkin" > 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