Red Hat Bugzilla – Bug 195429
info threads crashes if zombie threads exist
Last modified: 2015-01-07 19:12:58 EST
Description of problem:
This is still broken in GDB mainline.
If you run GDB's testsuite's print-threads program within GDB and single-step
main until some thread enters zombie state, and at that point run info threads,
GDB will crash because prune_threads() in the beginning of
info_threads_command() deletes the thread from the thread_list because it's no
longer active, but iterating over threads still sees them, and then crashes as
Version-Release number of selected component (if applicable):
gdb-22.214.171.124-1.130, rawhide, GDB trunk in upstream CVS
Sometimes, but not always
Steps to Reproduce:
1.Start print-threads within GDB
2.Single-step in main
3.Run `info threads' after every pthread_create
Alternate reproducer (works every time, at least in rawhide):
1.Start print-threads within GDB
2.Set a breakpoint in siglongjmp or in __pthread_unwind
3.Run the program
4.When the program stops at the breakpoint, run `info threads'
Most often, GDB will crash at `info threads', when switch_to_thread() tries to
read the PC from the deleted thread, which ultimately calls
thread_db_fetch_registers() with an inferior_ptid that is no longer in
thread_list, such that find_thread_pid() returns NULL, and then
thread_db_map_id2thr(thread_info, 1) crashes when it dereferences thread_info.
Sometimes GDB will print errors such as:
Cannot insert breakpoint -16.
Error accessing memory address 0x1170650b: Input/output error.
with nonsensical memory addresses. Such addresses are extracted from a jmpbuf
that is longjmp()ed to as part of thread unwinding started by pthread_exit().
This might be related to the crash, or it might just be that GDB extracts the
wrong address for some yet-to-be-determined reason.
No such crash
longjmp problem split into bug 195449.
Created attachment 131139 [details]
Draft patch (for GDB-CVS) proposal for handling+tracing behing pthread_exit(3)
Patch disables handling of the TD_DEATH notification from __nptl_death_event()
and tries to keep the thread in TD_THR_ZOMBIE state as long as possible before
its LWP ceases to be. While expecting regressions so far no such was found,
statistically it improves some testcases (+24 passes,-14 fails), no negatives.
('longjmp' part not resolved; not reproducible for GDB-CVS)
It has been fixed (and I successfully tested it) different way in the upstream CVS.
To be closed as CLOSED-NEXTRELEASE? It will not make it to RHEL5, though.
2006-07-12 Daniel Jacobowitz <firstname.lastname@example.org>
* linux-thread-db.c (td_thr_getfpregs_p, td_thr_getgregs_p)
(td_thr_setfpregs_p, td_thr_setgregs_p, thread_db_get_info)
(thread_db_load): Don't look up regset functions.
(init_thread_db_ops): Do not set to_fetch_registers,
to_store_registers, or to_thread_alive.
Can we backport the fixes, please?
Created attachment 134272 [details]
Trivia backport of the CVS patch
Patch backported and successfully tested on RHEL4U3
on top of
Still the patch should not be needed for setting the RHEL-4.5 flags, if I
understand the process.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
* Tue Oct 5 2006 Jan Kratochvil <email@example.com> - 126.96.36.199-1.135
- Avoid crash of 'info threads' if stale threads exist (BZ 195429).
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.