Re: gdb 6.2 blockers

[Daniel Jacobowitz <drow@false.org>]

On Wed, Jul 07, 2004 at 11:26:32AM -0400, Andrew Cagney wrote:
> More edits:
> 
> >1650: I suspect this is really a kernel race condition.
> >I remember that Jeff was pointing out that the bug this tickles is a race 
> >condition (hence isn't always reproducable).  The fix for NPTL involves 
> >kernel changes, I'm not sure about linuxthreads.
> I couldn't get the test to fail on NPTL -> linuxthreads specific.

Ditto; one failure mode on LinuxThreads is:
(gdb) PASS: gdb.threads/manythreads.exp: info threads
continue
Continuing.
PASS: gdb.threads/manythreads.exp: second continue
(gdb) Quit
(gdb) FAIL: gdb.threads/manythreads.exp: stop threads 2

We stop threads for no apparent reason and then the C-c is handled at
the prompt.

Another is:
(gdb) PASS: gdb.threads/manythreads.exp: shell stty intr '^C'
continue
Continuing.
PASS: gdb.threads/manythreads.exp: first continue
/opt/src/gdb/src/gdb/lin-lwp.c:645: internal-error: wait_lwp: Assertion `lp->status == 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
FAIL: gdb.threads/manythreads.exp: stop threads 1 (GDB internal error)

Jeff's presumably right about the race condition.  Did he investigate
at all?  The error means the waitstatus state machine in lin-lwp is
somehow broken.

-- 
Daniel Jacobowitz