From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17526 invoked by alias); 13 Dec 2001 20:31:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 16034 invoked from network); 13 Dec 2001 20:29:59 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 13 Dec 2001 20:29:59 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16EcUQ-0007sX-00; Thu, 13 Dec 2001 15:29:58 -0500 Date: Thu, 13 Dec 2001 12:31:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Don't use thread_db on corefiles Message-ID: <20011213152958.A30211@nevyn.them.org> Mail-Followup-To: Michael Snyder , gdb-patches@sources.redhat.com References: <20011213114847.A17989@nevyn.them.org> <3C190DDC.B32D6A7B@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C190DDC.B32D6A7B@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-12/txt/msg00359.txt.bz2 On Thu, Dec 13, 2001 at 12:21:48PM -0800, Michael Snyder wrote: > Daniel Jacobowitz wrote: > > > > This patch fixes a really frustrating internal error when you open the > > coredump of a multithreaded application. Depending on your kernel, either > > the core has threads (corefile.c supports this just fine) or it doesn't. > > Neither way will opening libthread_db work right. > > Daniel, what exactly is the problem that you are solving? > What do you mean by "work right"? Work at all. Witness: drow@nevyn:~/crash% gdb ./lotsa_um core GNU gdb 5.1 Copyright 2001 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-linux"... Core was generated by `./lotsa_um'. Reading symbols from /lib/libpthread.so.0...done. warning: Unable to set global thread event mask: generic error [New Thread 1024 (LWP 153)] Error while reading shared library symbols: Cannot enable thread event reporting for Thread 1024 (LWP 153): generic error Reading symbols from /lib/librt.so.1...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 main (argc=1, argv=0xbffffec4) at lotsa_crash.c:35 35 *(int *) 0 = 0; (gdb) info threads ../../gdb/lin-lwp.c:1292: gdb-internal-error: lin_lwp_thread_alive: Assertion `is_lwp (ptid)' failed. An internal GDB error was detected. This may make further debugging unreliable. Continue this debugging session? (y or n) > > This patch isn't quite complete, because strange things happen when you > > connect to a remote target too. But fixing that requires a little more > > fiddling. > > I don't think that "target_has_execution" is the right thing > to be testing here, if what you're really looking for is > "is this a corefile?" Well, the errors are on trying to write to inferior memory mostly. Tieing that to target_has_execution made sense to me. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer