[Bug gdb/26562] New: gdb follows both sides of a clone2(CLONE_PIDFD) on Linux >= 5.4

[Bug gdb/26562] New: gdb follows both sides of a clone2(CLONE_PIDFD) on Linux >= 5.4

[thiago at kde dot org]

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

            Bug ID: 26562
           Summary: gdb follows both sides of a clone2(CLONE_PIDFD) on
                    Linux >= 5.4
           Product: gdb
           Version: 10.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: thiago at kde dot org
  Target Milestone: ---

Created attachment 12813
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12813&action=edit
testcase

Ref: https://bugreports.qt.io/browse/QTBUG-86319

Linux 5.2 added CLONE_PIDFD support to the clone() system call. As of Linux
5.4, this system call is usable in libraries to avoid having to install SIGCHLD
handlers, which can't be done thread-safely, and can't be uninstalled safely at
all (whether single-threaded or not).

Qt has support for this since version 5.15.0.

However, we've noticed that gdb does not seem to detect that the clone() system
call created a child process that should be detached from after the fork and
not kept in debug state. What's more, the child's execve() seems to entirely
confuse gdb and cause it to no longer know what process or executable it's
debugging.

Compile the attached testcase for both situations. Then start gdb and place a
breakpoint on line 112:
    sys_waitid(P_PIDFD, pidfd, &si, __WALL | WEXITED, NULL);

When that breakpoint hits, the gdb reports the following thread state:

Thread 1 "a.out" hit Breakpoint 1, main () at ./forkfdtest.c:112
112         sys_waitid(P_PIDFD, pidfd, &si, __WALL | WEXITED, NULL);
(gdb) i thr
  Id   Target Id          Frame 
* 1    LWP 246005 "a.out" main () at ./forkfdtest.c:112
  2    LWP 246009         __GI___clock_nanosleep (clock_id=clock_id@entry=0,
flags=flags@entry=0, req=req@entry=0x7fffffffd950, 
    rem=rem@entry=0x7fffffffd950) at
../sysdeps/unix/sysv/linux/clock_nanosleep.c:79

Note this second thread that shouldn't be there. 

The second problem shows up after this sys_waittid call returns. GDB gets
completely confused:

(gdb) n
process 246005 is executing new program: /usr/bin/true
Error in re-setting breakpoint 1: No source file named /tmp/forkfdtest.c.
[New LWP 246005]

Thread 3 "a.out" received signal SIGTRAP, Trace/breakpoint trap.
0x0000000000401317 in ?? ()
(gdb) i thr
  Id   Target Id          Frame 
  2    LWP 246009         0x00007ffff7fdddc6 in _dl_new_object
(realname=realname@entry=0x7ffff7ffed10 "/lib64/libc.so.6", 
    libname=libname@entry=0x555555554ae1 "libc.so.6", type=type@entry=1,
loader=loader@entry=0x7ffff7ffe140, mode=mode@entry=0, 
    nsid=nsid@entry=0) at dl-object.c:95
* 3    LWP 246005 "a.out" 0x0000000000401317 in ?? ()

The original process is still there (same PID), but is now reported as thread
3, not 1. The symbol table has clearly changed too, as gdb followed on to a
different process. And if you're not paying attention, you won't notice that
the target file also changed, so you can't restart debugging:

(gdb) i files
Symbols from "/usr/bin/true".
Local exec file:
        `/usr/bin/true', file type elf64-x86-64.
[...]
(gdb) r
Starting program: /usr/bin/true 
[Inferior 1 (process 246843) exited normally]

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

[Bug gdb/26562] gdb follows both sides of a clone2(CLONE_PIDFD) on Linux >= 5.4

[thiago at kde dot org]

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

Thiago Macieira <thiago at kde dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #1 from Thiago Macieira <thiago at kde dot org> ---
Update: looks like the issue is that the code is not passing SIGCHLD as the
termination signal to clone(), which causes the kernel to send
PTRACE_EVENT_CLONE instead of PTRACE_EVENT_FORK. That confuses gdb.

Changing the clone code fixed the problem.

It's still technically a bug in gdb, but not worth fixing.

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