threads/2270: Linux pthreads

[dietmar at sourceware dot org, petras at sourceware dot org, at at sourceware dot org, coware at sourceware dot org]

>Number:         2270
>Category:       threads
>Synopsis:       Linux pthreads
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jun 09 10:58:01 UTC 2007
>Closed-Date:
>Last-Modified:
>Originator:     dietmar petras at coware
>Release:        gdb-6.6
>Organization:
>Environment:
Red Hat Enterprise Linux ES release 4 (Nahant Update 3), Linux version 2.6.9-34.ELsmp
>Description:
When attaching to a multithreading process under linux (using pthreads),
thread data of a previous process is still available and thread ids do not
start with 1.

To reproduce have a program with pthreads.

1. start the program from the shell
2. attach GDB to the running process.
3. do info threads, all threads are listed starting with #1
4. let the program exit normally while GDB is attached.
5. re-start the program from the shell
6. attach GDB to the running process.
6a: do info threads, all threads are listed but starting with a number >> 1

or

6b: do a thread 1, call any_function(). This may produce strange errors,
  since thread 1 still contains the info of the old inferior

Looking into the GDB sources I found that init_thread_list() is never
called when the process exits and GDB attaches to the new process. During
attach GDB does not execute thread_db_attach() but thread_db_new_objfile().


If GDB detaches from the process before the process exits, and GDB attaches
to the restarted process, then everything is fine.

Again looking into the sources I found that this time GDB executes
thread_db_attach() which clears the thread list with a init_thread_list().

Regards,

Dietmar Petras at CoWare inc., SJ, CA
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: