Commit graph

2 commits

Author SHA1 Message Date
Pedro Alves
511aee7c39 gdb.threads/clone-thread_db.c: Add missing includes and fix pthread_join call
This fixes:

> gdb compile failed, /gdb/testsuite/gdb.threads/clone-thread_db.c: In function 'main':
> /gdb/testsuite/gdb.threads/clone-thread_db.c:67:3: warning: implicit declaration of function 'alarm' [-Wimplicit-function-declaration]
>    alarm (300);
>    ^
> /gdb/testsuite/gdb.threads/clone-thread_db.c:69:3: warning: implicit declaration of function 'pthread_create' [-Wimplicit-function-declaration]
>    pthread_create (&child, NULL, thread_fn, NULL);
>    ^
> /gdb/testsuite/gdb.threads/clone-thread_db.c:70:3: warning: implicit declaration of function 'pthread_join' [-Wimplicit-function-declaration]
>    pthread_join (child);
>    ^

And then adding the missing headers revealed the pthread_join call was
incorrect.  This probably fixes the crash we see on ppc64be, e.g., at

 https://sourceware.org/ml/gdb-testers/2015-q1/msg04415.html

the logs there show:

 ...
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x3fffb7ff54a0 (LWP 9275)]
 0x00003fffb7f3ce74 in .pthread_join () from /lib64/libpthread.so.0
 (gdb) FAIL: gdb.threads/clone-thread_db.exp: continue to end
 ...

Tested on x86_64 Fedora 20.

gdb/testsuite/
2015-03-04  Pedro Alves  <palves@redhat.com>

	* gdb.threads/clone-thread_db.c: Include unistd.h and pthread.h.
	(main): Pass missing retval argument to pthread_join call.
2015-03-04 09:13:49 +00:00
Pedro Alves
5c5019c27c 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.
2015-02-20 19:00:21 +00:00