[Bug threads/18006] New: internal error if threaded program calls clone(CLONE_VM)

[Bug threads/18006] New: internal error if threaded program calls clone(CLONE_VM)

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18006

            Bug ID: 18006
           Summary: internal error if threaded program calls
                    clone(CLONE_VM)
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: threads
          Assignee: unassigned at sourceware dot org
          Reporter: palves at redhat dot com

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.

On GDB 7.9, the crash looks like:

 (gdb) break clone_fn
 Breakpoint 2 at 0x4007d8: file clone-thread_db.c, line 35.
 (gdb) r
 ...
 [Thread debugging using libthread_db enabled]
 ...
 /home/pedro/gdb/mygit/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.

On earlier releases, it looked like this:

 (gdb) b clone_fn 
 Breakpoint 1 at 0x4007d8: file clone-thread_db.c, line 35.
 (gdb) r
 ...
 [Thread debugging using libthread_db enabled]
 ...
 [New Thread 0x7ffff7fc2700 (LWP 3886)]
 ../../gdb/linux-thread-db.c:437: internal-error: thread_get_info_callback:
Assertion `inout->thread_info != NULL' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/18006] internal error if threaded program calls clone(CLONE_VM)

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18006

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at sourceware dot org   |palves at redhat dot com

--- Comment #1 from Pedro Alves <palves at redhat dot com> ---
Mine.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/18006] internal error if threaded program calls clone(CLONE_VM)

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18006

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <palves@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5c5019c27c5a4a73ec53281b4b69044f82b179f0

commit 5c5019c27c5a4a73ec53281b4b69044f82b179f0
Author: Pedro Alves <palves@redhat.com>
Date:   Fri Feb 20 19:00:21 2015 +0000

    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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/18006] internal error if threaded program calls clone(CLONE_VM)

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18006

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Pedro Alves <palves at redhat dot com> ---
Fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.