This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa/PROBLEMS] document threads/1650, thread internal error
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