This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: linux-thread-db.c not only caller of add_thread, -> gdb segv
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]