public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "thiago at kde dot org" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug gdb/26562] New: gdb follows both sides of a clone2(CLONE_PIDFD) on Linux >= 5.4 Date: Tue, 01 Sep 2020 15:36:53 +0000 [thread overview] Message-ID: <bug-26562-4717@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2020-09-01 15:36 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-01 15:36 thiago at kde dot org [this message] 2020-09-17 20:26 ` [Bug gdb/26562] " thiago at kde dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-26562-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).