gdb 6.2 blockers
Daniel Jacobowitz
drow@false.org
Wed Jul 7 16:12:00 GMT 2004
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
More information about the Gdb
mailing list