This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: gdb/568, messy thread exits
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