From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28342 invoked by alias); 31 Jul 2002 21:01:08 -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 28284 invoked from network); 31 Jul 2002 21:01:06 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 31 Jul 2002 21:01:06 -0000 Received: from dsl254-114-118.nyc1.dsl.speakeasy.net ([216.254.114.118] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17a0ai-0008Jj-00; Wed, 31 Jul 2002 16:01:08 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17a0ai-0001h7-00; Wed, 31 Jul 2002 17:01:08 -0400 Date: Wed, 31 Jul 2002 14:04:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: gdb/568, messy thread exits Message-ID: <20020731210108.GA6364@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com References: <20020731163910.GA5622@nevyn.them.org> <20020731202940.GA16310@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-07/txt/msg00634.txt.bz2 On Wed, Jul 31, 2002 at 03:55:17PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > Here's the interesting part. It occurs whenever thread_db can not look > > up the LWP<->Thread mapping in the child. If, for instance, the child > > has disappeared, we can not look up its mapping any more. Or if some > > other circumstance causes the mapping to be unavailable, like an > > exec(); there's another PR about that case. > > I dunno. I mean, if someone asks you to look up a TID's LWP, and you > can't, that seems like an error, no? Isn't it supposed to be better > to flag errors early than let the thing go crashing on through the > forest with bogus information? Well, yes; except for the fact that this is on the exit path, so if we call error(), we tend to get stuck. This is a fairly frequent GDB problem. > I'm glad you found a patch that addresses the PR I filed, but there's > no way I can approve this patch --- not because I'm sure it's wrong, > but because I'm sure I have no idea whether it's right or wrong. :) Thanks for looking at it. I'll wait for Kevin or Michael to have time for it. > > > Of course, it is also my opinion that we perform the mapping a stupid > > number of times. ``set debug target 1'' and run a threaded program; > > you'll see it happen over and over again. > > Yes, I noticed this: amazing numbers of huge memory transfers. Yuck. > -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer