Re: RFA: gdb/568, messy thread exits

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Jul 31, 2002 at 03:23:08PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > Jim, what do you think about this change?  This fixes a whole class of
> > problems for me, by not longjmp'ing out of attempts to
> > kill/detach/quit/etc.
> 
> I'm not sure I can review this change very helpfully; I'm not very
> familiar with the threading code.
> 
> Can you go into more detail about why this change is adequate?  I
> mean, the ptid argument is generally not going to be an lwp, right?
> Shouldn't this function at least return a ptid that's an LWP?

The first bit of the function just returns whatever PTID it was passed
if we weren't given a thread.  As such, I'm not terribly worried about
the type of PTID we return.

> Under what situations does this error occur?

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.

If we allow this to be a fatal error here, we very easily get stuck
somewhere we can not recover from.

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.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer