diff options
author | Pedro Alves <palves@redhat.com> | 2015-02-20 19:00:21 +0000 |
---|---|---|
committer | Pedro Alves <palves@redhat.com> | 2015-02-20 19:00:21 +0000 |
commit | 5c5019c27c5a4a73ec53281b4b69044f82b179f0 (patch) | |
tree | c8780b0197de5bafa53dad7604134b0a1a8245c1 /gdb/linux-thread-db.c | |
parent | f3978e91005fc54b695779d3fc9c67f8e203d28a (diff) | |
download | gdb-5c5019c27c5a4a73ec53281b4b69044f82b179f0.zip gdb-5c5019c27c5a4a73ec53281b4b69044f82b179f0.tar.gz gdb-5c5019c27c5a4a73ec53281b4b69044f82b179f0.tar.bz2 |
PR18006: internal error if threaded program calls clone(CLONE_VM)
On GNU/Linux, if a pthreaded program has a thread call clone(CLONE_VM)
directly, and then that clone LWP hits a debug event (breakpoint,
etc.) GDB internal errors. Threaded programs shouldn't really be
calling clone directly, but GDB shouldn't crash either.
The crash looks like this:
(gdb) break clone_fn
Breakpoint 2 at 0x4007d8: file clone-thread_db.c, line 35.
(gdb) r
...
[Thread debugging using libthread_db enabled]
...
src/gdb/linux-nat.c:1030: internal-error: lin_lwp_attach_lwp: Assertion `lwpid > 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
The problem is that 'clone' ends up clearing the parent thread's tid
field in glibc's thread data structure. For x86_64, the glibc code in
question is here:
sysdeps/unix/sysv/linux/x86_64/clone.S:
...
testq $CLONE_THREAD, %rdi
jne 1f
testq $CLONE_VM, %rdi
movl $-1, %eax <----
jne 2f
movl $SYS_ify(getpid), %eax
syscall
2: movl %eax, %fs:PID
movl %eax, %fs:TID <----
1:
When GDB refreshes the thread list out of libthread_db, it finds a
thread with LWP with pid -1 (the clone's parent), which naturally
isn't yet on the thread list. GDB then tries to attach to that bogus
LWP id, which is caught by that assertion.
The fix is to detect the bad PID early.
Tested on x86-64 Fedora 20. GDBserver doesn't need any fix.
gdb/ChangeLog:
2015-02-20 Pedro Alves <palves@redhat.com>
PR threads/18006
* linux-thread-db.c (thread_get_info_callback): Return early if
the thread's lwp id is -1.
gdb/testsuite/ChangeLog:
2015-02-20 Pedro Alves <palves@redhat.com>
PR threads/18006
* gdb.threads/clone-thread_db.c: New file.
* gdb.threads/clone-thread_db.exp: New file.
Diffstat (limited to 'gdb/linux-thread-db.c')
-rw-r--r-- | gdb/linux-thread-db.c | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/gdb/linux-thread-db.c b/gdb/linux-thread-db.c index 6b525a0..60d8742 100644 --- a/gdb/linux-thread-db.c +++ b/gdb/linux-thread-db.c @@ -431,6 +431,14 @@ thread_get_info_callback (const td_thrhandle_t *thp, void *argp) error (_("thread_get_info_callback: cannot get thread info: %s"), thread_db_err_str (err)); + if (ti.ti_lid == -1) + { + /* We'll get this if a threaded program has a thread call clone + with CLONE_VM. `clone' sets the pthread LID of the new LWP + to -1, which ends up clearing the parent thread's LID. */ + return 0; + } + /* Fill the cache. */ thread_ptid = ptid_build (info->pid, ti.ti_lid, 0); inout->thread_info = find_thread_ptid (thread_ptid); |