* [rfa/PROBLEMS] document threads/1650, thread internal error
@ 2004-07-26 15:48 Michael Chastain
2004-07-26 17:45 ` Eli Zaretskii
2004-07-26 19:51 ` Andrew Cagney
0 siblings, 2 replies; 6+ messages in thread
From: Michael Chastain @ 2004-07-26 15:48 UTC (permalink / raw)
To: eliz; +Cc: gdb-patches
Here is a PROBLEMS entry for gdb/1650, the internal error on
gdb.threads/manythreads.exp.
Not tested (don't know how to test ascii documentation). The internal
error still happens with both gdb HEAD and gdb gdb_6_2-branch. Andrew
says that a set of 30 test runs with NPTL worked fine.
Okay to apply to gdb HEAD?
Okay to apply to gdb gdb_6_2-branch?
Michael C
2004-07-26 Michael Chastain <mec.gnu@mindspring.com>
Document PR threads/1650.
* PROBLEMS (Threads): Document problem with many threads
Index: PROBLEMS
===================================================================
RCS file: /cvs/src/src/gdb/PROBLEMS,v
retrieving revision 1.32
diff -c -3 -p -r1.32 PROBLEMS
*** PROBLEMS 18 Jul 2004 22:29:40 -0000 1.32
--- PROBLEMS 26 Jul 2004 15:44:21 -0000
*************** Fortunately, PowerPC architecture suppor
*** 129,131 ****
--- 129,149 ----
have been updated. People encountering problems should consider
downloading a more current snapshot of GDB
(http://www.gnu.org/software/gdb/current/).
+
+ *** Threads
+
+ threads/1650: manythreads.exp
+
+ A program which creates many threads which exit very quickly (hundreds
+ of thousands of threads in the test program) can cause gdb to generate
+ an internal error. The internal error often looks like:
+
+ lin-lwp.c:744: internal-error: stop_callback: Assertion `lp->status == 0' failed.
+ A problem internal to GDB has been detected.
+ further debugging may prove unreliable.
+ Quit this debugging session? (y or n)
+
+ This has been observed on native i686-pc-linux-gnu with linuxthreads,
+ the old threading model. With NPTL threads, this internal error has not
+ been observed.
+
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [rfa/PROBLEMS] document threads/1650, thread internal error
2004-07-26 15:48 [rfa/PROBLEMS] document threads/1650, thread internal error Michael Chastain
@ 2004-07-26 17:45 ` Eli Zaretskii
2004-07-27 0:08 ` Michael Chastain
2004-07-26 19:51 ` Andrew Cagney
1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2004-07-26 17:45 UTC (permalink / raw)
To: Michael Chastain; +Cc: gdb-patches
> Date: Mon, 26 Jul 2004 11:48:38 -0400 (EDT)
> From: mec.gnu@mindspring.com (Michael Chastain)
>
> Here is a PROBLEMS entry for gdb/1650, the internal error on
> gdb.threads/manythreads.exp.
Fine with me, thanks.
> Not tested (don't know how to test ascii documentation).
I think posting it here for review is all the ``testing'' it needs.
> Okay to apply to gdb HEAD?
> Okay to apply to gdb gdb_6_2-branch?
Yes, to both, IMHO: documentation can never screw up anything. But
I'll let Andrew to say the definitive YES/NO for the branch part.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [rfa/PROBLEMS] document threads/1650, thread internal error
2004-07-26 15:48 [rfa/PROBLEMS] document threads/1650, thread internal error Michael Chastain
2004-07-26 17:45 ` Eli Zaretskii
@ 2004-07-26 19:51 ` Andrew Cagney
2004-07-27 0:32 ` Michael Chastain
1 sibling, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2004-07-26 19:51 UTC (permalink / raw)
To: Michael Chastain; +Cc: eliz, gdb-patches
> +
> + *** Threads
> +
> + threads/1650: manythreads.exp
> +
> + A program which creates many threads which exit very quickly (hundreds
> + of thousands of threads in the test program) can cause gdb to generate
> + an internal error. The internal error often looks like:
> +
> + lin-lwp.c:744: internal-error: stop_callback: Assertion `lp->status == 0' failed.
> + A problem internal to GDB has been detected.
> + further debugging may prove unreliable.
> + Quit this debugging session? (y or n)
> +
> + This has been observed on native i686-pc-linux-gnu with linuxthreads,
> + the old threading model. With NPTL threads, this internal error has not
> + been observed.
> +
I think it more clearly needs to convey the following information:
- that it is (to the best of our knowledge) GNU/Linux and LinuxThreads
specific
So the opening sentence should mention both of those data points.
Something like ``On a GNU/Linux system that uses linuxthreads, a program
....''
- switching to NPTL highly recommended
So the closing paragraph should make this clearer. Something like
``This problem has not been observed on GNU/Linux systems that use NPTL
(New Posix Threads Library[?]). People still using linuxthreads are
strongly encouraged to migrate to NPTL''.
We should also mention that on GNU/Linux NPTL based systems a problem
with GDB loosing track of threads was fixed.
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [rfa/PROBLEMS] document threads/1650, thread internal error
2004-07-26 17:45 ` Eli Zaretskii
@ 2004-07-27 0:08 ` Michael Chastain
0 siblings, 0 replies; 6+ messages in thread
From: Michael Chastain @ 2004-07-27 0:08 UTC (permalink / raw)
To: eliz; +Cc: gdb-patches
eliz> I'll let Andrew to say the definitive YES/NO for the branch part.
Committed to gdb HEAD.
Andrew, how about the branch?
===
2004-07-26 Michael Chastain <mec.gnu@mindspring.com>
Document PR threads/1650.
* PROBLEMS (Threads): Document problem with many threads
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [rfa/PROBLEMS] document threads/1650, thread internal error
2004-07-26 19:51 ` Andrew Cagney
@ 2004-07-27 0:32 ` Michael Chastain
2004-07-27 15:28 ` Andrew Cagney
0 siblings, 1 reply; 6+ messages in thread
From: Michael Chastain @ 2004-07-27 0:32 UTC (permalink / raw)
To: cagney; +Cc: gdb-patches, eliz
Argh, I should have read to the end of my mailbox before committing
to gdb HEAD.
> - that it is (to the best of our knowledge) GNU/Linux and LinuxThreads
> specific
Good question, but your answer is wrong. Looking at gdb-testers@ for
June and July, I see that hppa2.0w-hp-hpux11.00 and
ia64-unknown-linux-gnu have this problem. Many other arches can't
compile manythreads.c so we can't tell either way.
native alphaev67-dec-osf5.1
couldn't compile the thread tests, so no evidence either way
native hppa??-??-linux-gnu
manythreads.exp is okay
native hppa2.0w-hp-hpux11.00
manythreads.exp reports these FAILs
native i686-pc-cygwin
manythreads.exp is okay
native ia64-unknown-linux gnu
gdb HEAD crashes several times timeouts in the threads tests; can't
even tell if manythreads.exp is running because gdb.sum has plenty
of "ERROR: internal buffer is full" nearby.
native powerpc-ibm-aix4.3.3.0
couldn't compile the thread tests, so no evidence either way
native powerpc-ibm-aix5.1.0.0
manythreads.exp reports these FAILS.
native sparc-sun-solaris 2.8
couldn't compile this particular test, so no evidence either way
native x86_64-unknown-linux-gnu
couldn't compile this particular test, so no evidence either way
> So the closing paragraph should make this clearer. Something like
> ``This problem has not been observed on GNU/Linux systems that use NPTL
> (New Posix Threads Library[?]). People still using linuxthreads are
> strongly encouraged to migrate to NPTL''.
Shouldn't that be in NEWS? Maybe I've missed some discussion,
but it's news to me that users linuxthreads are encouraged to
switch.
> We should also mention that on GNU/Linux NPTL based systems a problem
> with GDB loosing track of threads was fixed.
That sounds good.
Michael C
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [rfa/PROBLEMS] document threads/1650, thread internal error
2004-07-27 0:32 ` Michael Chastain
@ 2004-07-27 15:28 ` Andrew Cagney
0 siblings, 0 replies; 6+ messages in thread
From: Andrew Cagney @ 2004-07-27 15:28 UTC (permalink / raw)
To: Michael Chastain; +Cc: gdb-patches, eliz
> Argh, I should have read to the end of my mailbox before committing
> to gdb HEAD.
>
>
>>> - that it is (to the best of our knowledge) GNU/Linux and LinuxThreads
>>> specific
>
>
> Good question, but your answer is wrong.
Outch!
> Looking at gdb-testers@ for
> June and July, I see that hppa2.0w-hp-hpux11.00 and
> ia64-unknown-linux-gnu have this problem. Many other arches can't
> compile manythreads.c so we can't tell either way.
I thought HP/UX threads are pretty much busted anyway. Since it isn't a
LinuxThreads / libthread_db system, I'd assume (with out strong evidence
to the contrary) that the testsuite failure is due to a bug in the HP/UX
code.
>>> So the closing paragraph should make this clearer. Something like
>>> ``This problem has not been observed on GNU/Linux systems that use NPTL
>>> (New Posix Threads Library[?]). People still using linuxthreads are
>>> strongly encouraged to migrate to NPTL''.
>
>
> Shouldn't that be in NEWS? Maybe I've missed some discussion,
> but it's news to me that users linuxthreads are encouraged to
> switch.
It's our workaround to a problem.
>>> We should also mention that on GNU/Linux NPTL based systems a problem
>>> with GDB loosing track of threads was fixed.
>
>
> That sounds good.
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-07-27 15:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-07-26 15:48 [rfa/PROBLEMS] document threads/1650, thread internal error Michael Chastain
2004-07-26 17:45 ` Eli Zaretskii
2004-07-27 0:08 ` Michael Chastain
2004-07-26 19:51 ` Andrew Cagney
2004-07-27 0:32 ` Michael Chastain
2004-07-27 15:28 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox