From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19588 invoked by alias); 13 Dec 2001 22:59:56 -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 19321 invoked from network); 13 Dec 2001 22:58:37 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 13 Dec 2001 22:58:37 -0000 Received: from cygnus.com (reddwarf.cygnus.com [205.180.231.12]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA08060; Thu, 13 Dec 2001 14:58:36 -0800 (PST) Message-ID: <3C1931E3.E240B409@cygnus.com> Date: Thu, 13 Dec 2001 14:59:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: [RFA] Don't use thread_db on corefiles References: <20011213114847.A17989@nevyn.them.org> <3C190DDC.B32D6A7B@cygnus.com> <20011213152958.A30211@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2001-12/txt/msg00362.txt.bz2 Daniel Jacobowitz wrote: > > 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: What the heck kind of core file is this? I've never seen the behavior you're getting. GDB certainly works for standard corefiles on Linux (which BTW don't have any thread info in them). > > 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