Re: RFA: gdb/568, messy thread exits

[Daniel Jacobowitz <drow@mvista.com>]

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 <drow@mvista.com>
> > >
> > >    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