[Bug gdb/28276] New: Threads are running with breakpoints removed when handling vfork

[Bug gdb/28276] New: Threads are running with breakpoints removed when handling vfork

[simark at simark dot ca]

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

            Bug ID: 28276
           Summary: Threads are running with breakpoints removed when
                    handling vfork
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: simark at simark dot ca
  Target Milestone: ---

I looked into how GDB handles vfork, especially by multi-threaded programs. I
believe that the way it works right now is fundamentally broken, here's why.

When a program vforks, the parent is suspended by the kernel until the child
exits or execs (that is, when the parent and child stop sharing the address
space). However, in a multi-threaded program, only the thread that called vfork
is suspended. Other threads keep running freely. This is documented in the
vfork man page.

Let's suppose GDB is handling a vfork and the user's desire is to detach from
the child. Before detaching the child, it must remove the software breakpoints
inserted in the shared parent/child address space. Otherwise the child could
potentially hit a breakpoint instruction while running outside the control of
GDB. GDB must also avoid re-inserting breakpoints in the parent as long as it
didn't receive the "vfork done" event (that is, when the child has exited or
execed): since the address space is shared with the child, that would re-insert
breakpoints in the child's process. So what GDB does is:

1. Receive "vfork" event for the parent
2. Remove breakpoints
3. Detach from the child
4. Resume the parent
5. Wait for and receive "vfork done" event for the parent
6. Re-insert breakpoints
7. Resume the parent

Note that step #4 is probably (I haven't verified) necessary in order for the
kernel to generate the "vfork done" event. I presume that the kernel won't
generate ptrace events for threads that are ptrace-stopped. But the theory is
that between steps 4 and 5, the parent won't actually do any progress, because
the kernel keeps it suspended, waiting for the child to exit or exec, so it
doesn't matter if breakpoints are not inserted.

Now, the problem is when the program is multi-threaded. In step 4, GDB resumes
all threads of the parent. The thread that did the vfork stays suspended, so
that's fine. But other threads are running freely while breakpoints are
removed, so they could miss a breakpoint that they should have hit.

With a non-stop target, it's a bit different but also results in the other
threads running while breakpoints are removed: the other threads are simply
never stopped.

I believe that with all-stop targets, GDB should only resume the vfork-ing
thread when waiting for the vfork done event, not all threads of the process. 
With non-stop targets, GDB should stop all threads, resume the vfork-ing
thread, wait for the vfork done event, and then resume all threads.  This
handling is similar to what we need to do for inline stepping.

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

[Bug gdb/28276] Threads are running with breakpoints removed when handling vfork

[simark at simark dot ca]

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

--- Comment #1 from Simon Marchi <simark at simark dot ca> ---
Created attachment 13628
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13628&action=edit
Reproducer

Here's a reproducer.  It shows the non-vforking thread missing a breakpoint.

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