Re: linux-thread-db.c not only caller of add_thread, -> gdb segv

["Douglas Evans" <dje@google.com>]

On Nov 9, 2007 6:02 AM, Daniel Jacobowitz <drow@false.org> wrote:
> This is true.  But if you're using the Linux native target, and reach
> the point where any of the other add_thread calls are made, then
> there's already a bug.  It is supposed to detect all new threads.
> It sort of has to - that's how infrun gets the new ptid_t.

Ah, thanks. I understand the threading support a bit better now.

[for completeness' sake, target = x86_64-linux]

> 3) Figure out how you got to any of the other add_thread calls.

Or that. :-)

I think I understand what's going on.  Consider a threaded app that
first exec's itself
(e.g. because it wants to be run with a specific value for LD_LIBRARY_PATH,
the actual reason doesn't matter though).

GDB doesn't properly handle the fact that the original process is gone.

GDB detects the exec and removes thread_db_ops from the target stack.
But (a) it doesn't clear out thread_list and (b) still thinks it has control of
the running process.
By the time GDB gets to handle_inferior_event() case TARGET_WAITKIND_EXECD
it has added the new process to thread_list with the call
to add_thread in infrun.c, and thus there's an entry in thread_list with
"private" == NULL.  thread_list also has stale entries at this point.

If the user does a ^c after the exec and then "info threads"
gdb will detect an internal error due to the stale entries in thread_list
and crash.

But if instead the user does a ^c and then "sharedlib some_library"
GDB will push thread_db_ops back on the target stack.
If the user then does "continue" thread_db_resume gets called and boom,
segv because thread->private == NULL in clear_lwpid_callback.

I'm working on a patch but I don't know this part of GDB very well.

[small test case available, I'll include it with the patch]