From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7354 invoked by alias); 21 Jun 2006 02:31:35 -0000 Received: (qmail 7346 invoked by uid 22791); 21 Jun 2006 02:31:34 -0000 X-Spam-Check-By: sourceware.org Received: from cse-mail.unl.edu (HELO cse-mail.unl.edu) (129.93.165.11) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 21 Jun 2006 02:31:32 +0000 Received: from [129.93.164.247] (cse-witty-01.unl.edu [129.93.164.247]) (authenticated bits=0) by cse-mail.unl.edu (8.13.6/8.13.5) with ESMTP id k5L2VOx1029455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jun 2006 21:31:29 -0500 (CDT) Message-ID: <4498AF77.4040607@cse.unl.edu> Date: Wed, 21 Jun 2006 02:33:00 -0000 From: Neo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "U. George" CC: gdb@sourceware.org Subject: Re: why is "gdb /home/gat/JAVA/JDK16/jdk1.6.0/bin/java" so broken? References: <43F76720.3050903@gatworks.com> In-Reply-To: <43F76720.3050903@gatworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (cse-mail.unl.edu [129.93.165.11]); Tue, 20 Jun 2006 21:31:29 -0500 (CDT) X-Virus-Status: Clean X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00166.txt.bz2 hi, I haven't check the source code for JDK1.6.0 yet. But I think it probably is the same as the code of JDK1.5. In JDK1.5, file java_md.c, itself will check if the LD_LIBRARY_PATH is set correct. If yes, it will continue execution. Otherwise, it will call execve() that will bring troubles to GDB. My workaround is to just set LD_LIBRARY_PATH correct, if you really are interested in debugging java_g. These days, I am debugging jdk 1.4.2. Although this trick will still work, I got a seg. fault later. Is there anybody else working on that problem? Thanks, Neo U. George wrote: > After some 60min of running javasoft's java, the program finally dies > of a segfault. I have been trying, and apparently for several years > now, according to the gdb bug base, to get GDB to work with java & > threads. > Version 6.4 does not work any better. > there is something wrong in libthread_db.so. I'm not yet willing to > just replace the libs, as this may affect the 'heap' bug that shows > itself randomly. > > So whats goin on with gdb? > > >> [gat@MyLaptop ~]$ gdb /home/gat/JAVA/JDK16/jdk1.6.0/bin/java >> GNU gdb Red Hat Linux (6.3.0.0-1.84rh) >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and >> you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "i386-redhat-linux-gnu"...(no debugging >> symbols found) >> Using host libthread_db library "/lib/tls/i686/libthread_db.so.1". >> >> (gdb) r >> Starting program: /home/gat/JAVA/JDK16/jdk1.6.0/bin/java >> Reading symbols from shared object read from target memory...(no >> debugging symbols found)...done. >> Loaded system supplied DSO at 0xd46000 >> (no debugging symbols found) >> [Thread debugging using libthread_db enabled] >> [New Thread 2251072 (LWP 2428)] >> (no debugging symbols found) >> (no debugging symbols found) >> (no debugging symbols found) >> (no debugging symbols found) >> Cannot find user-level thread for LWP 2428: generic error >> (gdb) > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using!