From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14166 invoked by alias); 27 Aug 2002 01:39:07 -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 14159 invoked from network); 27 Aug 2002 01:39:07 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 27 Aug 2002 01:39:07 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17jWFN-0001eB-00; Mon, 26 Aug 2002 21:38:25 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17jVK6-0003LX-00; Mon, 26 Aug 2002 21:39:14 -0400 Date: Mon, 26 Aug 2002 19:05:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: RFA: gdb/568, messy thread exits Message-ID: <20020827013914.GA10015@nevyn.them.org> Mail-Followup-To: Michael Snyder , Mark Kettenis , gdb-patches@sources.redhat.com References: <20020731163910.GA5622@nevyn.them.org> <20020812161447.GA770@nevyn.them.org> <200208132200.g7DM03vH034786@elgar.kettenis.dyndns.org> <20020813221350.GA14555@nevyn.them.org> <3D6AD68B.B6018428@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D6AD68B.B6018428@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00886.txt.bz2 On Mon, Aug 26, 2002 at 06:31:55PM -0700, Michael Snyder wrote: > Daniel Jacobowitz wrote: > > > > On Wed, Aug 14, 2002 at 12:00:03AM +0200, Mark Kettenis wrote: > > > Date: Mon, 12 Aug 2002 12:14:47 -0400 > > > From: Daniel Jacobowitz > > > > > > Michael, Mark - what do you think of this patch? A better explanation > > > of the patch is at: > > > http://sources.redhat.com/ml/gdb-patches/2002-07/msg00630.html > > > > > > It's a kludge. Therefore I'm not inclined to say that this can go in. > > > We should really fix things such that lwp_from_thread isn't called > > > under the circumstances where you're having problems, or we should > > > modify it such that it doesn't have to call td_ta_map_id2thr() under > > > those troublesome circumstances. > > > > > > If we can't come up with such a patch in a timely fashion, we could > > > decide to get this in, but not without a comment saying that it is a > > > kludge. > > > > Well, let me elaborate. > > > > lwp_from_thread consults data structures in the inferior, just like the > > rest of thread_db. As such, I have to consider it... "untrusted" if > > you will. The inferior crashes unexpectedly - we can't call > > lwp_from_thread any more. The inferior gets corrupted - we can't call > > lwp_from_thread any more. As such, I think we need to be at least a > > little more graceful with this function everywhere we touch it (which > > is far too often, if you look at the target traffic dumps). The same > > goes for any other request we make of thread_db. So the fixes would > > not be in calling it less, but in allowing it to fail (more) > > gracefully. > > You're right, there is a problem -- but this isn't the solution. > It's too simple. OK. I'm using this patch for now in the packages I maintain, because the warning at least lets the user exit without having to kill GDB. Meanwhile, we can try to address the real problems. If anyone actually has a suggestion on them, that is! > > To be honest, I gave up on this entirely. We don't support any > > non-one-to-one threads packages via thread-db.c; we've never tested > > with any unless someone's got one up their sleeve that they're not > > talking about. > > I believe the next major revision of glibc is expected > to include one-to-many thread mapping. At least it used > to be expected to... I don't think so, but I don't have complete information. For one thing, the next major LinuxThreads revision seems to have slipped beyond the next major glibc release; for another, given all the work Ingo Molnar's been putting in on minimal-overhead clone() and scalable scheduling for this new library, I doubt he'd advocate wedging multiple threads into a process. But the development is not happening in public, so I don't really know. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer