Bug 195429 - info threads crashes if zombie threads exist
info threads crashes if zombie threads exist
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gdb (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Kratochvil
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2006-06-15 02:11 EDT by Alexandre Oliva
Modified: 2015-01-07 19:12 EST (History)
4 users (show)

See Also:
Fixed In Version: RHSA-2007-0229
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-01 13:23:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Draft patch (for GDB-CVS) proposal for handling+tracing behing pthread_exit(3) (2.42 KB, patch)
2006-06-19 12:29 EDT, Jan Kratochvil
no flags Details | Diff
Trivia backport of the CVS patch (9.14 KB, patch)
2006-08-15 18:46 EDT, Jan Kratochvil
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2007:0229 normal SHIPPED_LIVE Low: gdb security and bug fix update 2007-05-01 13:21:30 EDT

  None (edit)
Description Alexandre Oliva 2006-06-15 02:11:17 EDT
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
described below.

Version-Release number of selected component (if applicable):
gdb-, rawhide, GDB trunk in upstream CVS

How reproducible:
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'

Actual results:
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.

Expected results:
No such crash

Additional info:
Comment 2 Alexandre Oliva 2006-06-15 05:34:22 EDT
longjmp problem split into bug 195449.
Comment 3 Jan Kratochvil 2006-06-19 12:29:06 EDT
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)
Comment 4 Jan Kratochvil 2006-07-29 19:08:00 EDT
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  <dan@codesourcery.com>

        * 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_fetch_registers, thread_db_store_registers)
        (thread_db_thread_alive): Delete.
        (thread_db_load): Don't look up regset functions.
        (thread_db_pid_to_str): Simplify.
        (init_thread_db_ops): Do not set to_fetch_registers,
        to_store_registers, or to_thread_alive.
Comment 5 Elena Zannoni 2006-08-14 15:20:48 EDT
Can we backport the fixes, please? 
Comment 6 Jan Kratochvil 2006-08-15 18:46:28 EDT
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.
Comment 10 RHEL Product and Program Management 2006-09-01 14:46:35 EDT
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
Comment 12 Jan Kratochvil 2006-10-09 19:30:12 EDT
* Tue Oct  5 2006 Jan Kratochvil <jan.kratochvil@redhat.com> -
- Avoid crash of 'info threads' if stale threads exist (BZ 195429).
Comment 16 Red Hat Bugzilla 2007-05-01 13:23:33 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.