Re: RFA: gdb/568, messy thread exits

Daniel Jacobowitz
2002-07-31T21:01:08Z

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