[Bug server/30574] New: hang when using remote target, schedule-multiple, follow-fork-mode child, and stepping over a vfork

["aburgess at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

            Bug ID: 30574
           Summary: hang when using remote target, schedule-multiple,
                    follow-fork-mode child, and stepping over a vfork
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: server
          Assignee: unassigned at sourceware dot org
          Reporter: aburgess at redhat dot com
  Target Milestone: ---

Created attachment 14941
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14941&action=edit
reproducer for this issue

When using a remote target and stepping over a vfork with follow-fork-mode set
to child, and schedule-multiple set to on, GDBServer will hang, which in turn
causes GDB to hang.

To reproduce the issue, download the atteached remote-vfork-bug.tar.bz2, and
then:

  $ tar -xf remote-vfork-bug.tar.bz2
  $ cd remote-vfork-bug/
  $ make GDB="/path/to/gdb"
  ... snip lots of output ...
  Breakpoint 1, main (argc=1, argv=0x7fffffffacb8) at test.c:11
  11      pid = vfork (); /* VFORK */
  [Attaching after Thread 2182093.2182093 vfork to child Thread
2182094.2182094]
  [New inferior 2 (process 2182094)]

At which point GDB hangs.

The problem appears to be that after the VFORK GDB resumes the vfork-child
process, but, due to schedule-multiple being on, this results in GDB sending a
ptid of -1 to gdbserver, this means resume everything.

I think this bit is fine, this is what happens with e.g. the linux-nat layer
within GDB, but in the linux-nat layer when we action the -1 ptid we loop over
all threads and resume them, except we spot that one thread is a vfork-parent
and specifically skip resuming that thread.

In contrast gdbserver doesn't skip the vfork-parent, and instead resumes the
vfork-parent.

While the vfork-child is running the kernel will hold the vfork parent stopped.

When the vfork-child execs gdbserver sees the event and tries to stop all
resumed threads, as the vfork-parent is resumed gdbserver sends it a SIGSTOP
and then waits for the thread to report a stop .... and it is this stop that
never arrives, and this is where we seem to hang.

Some of the details in the above might be a little off, I've only given this a
quick review before filing this bug.

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