Re: RFA: gdb/568, messy thread exits

[Daniel Jacobowitz <drow at mvista dot com>]

On Wed, Jul 31, 2002 at 03:55:17PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> 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