]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
[gdb] Handle vfork in thread with follow-fork-mode child
authorTom de Vries <tdevries@suse.de>
Thu, 18 Apr 2019 16:05:43 +0000 (17:05 +0100)
committerPedro Alves <palves@redhat.com>
Thu, 18 Apr 2019 16:05:43 +0000 (17:05 +0100)
commitb73715df01e6e9b3de5a49cd7bf4170deef48461
tree455f78a094cce44476c92fbde678b10bccbddcc3
parent5d5b0bd35f1f8b8484349c3ec51aa8e19a1627cf
[gdb] Handle vfork in thread with follow-fork-mode child

When debugging any of the testcases added by this commit, which do a
vfork in a thread with "set follow-fork-mode child" + "set
detach-on-fork on", we run into this assertion:

...
src/gdb/nat/x86-linux-dregs.c:146: internal-error: \
  void x86_linux_update_debug_registers(lwp_info*): \
  Assertion `lwp_is_stopped (lwp)' failed.
...

The assert is caused by the following: the vfork-child exit or exec
event is handled by handle_vfork_child_exec_or_exit, which calls
target_detach to detach from the vfork parent.  During target_detach
we call linux_nat_target::detach, which:

#1 - stops all the threads
#2 - waits for all the threads to be stopped
#3 - detaches all the threads

However, during the second step we run into this code in
stop_wait_callback:

...
  /* If this is a vfork parent, bail out, it is not going to report
     any SIGSTOP until the vfork is done with.  */
  if (inf->vfork_child != NULL)
    return 0;
...

and we don't wait for the threads to be stopped, which results in this
assert in x86_linux_update_debug_registers triggering during the third
step:

...
  gdb_assert (lwp_is_stopped (lwp));
...

The fix is to reset the vfork parent's vfork_child field before
calling target_detach in handle_vfork_child_exec_or_exit.  There's
already similar code for the other paths handled by
handle_vfork_child_exec_or_exit, so this commit refactors the code a
bit so that all paths share the same code.

The new tests cover both a vfork child exiting, and a vfork child
execing, since both cases would trigger the assertion.

The new testcases also exercise following the vfork children with "set
detach-on-fork off", since it doesn't seem to be tested anywhere.

Tested on x86_64-linux, using native and native-gdbserver.

gdb/ChangeLog:
2019-04-18  Tom de Vries  <tdevries@suse.de>
    Pedro Alves  <palves@redhat.com>

PR gdb/24454
* infrun.c (handle_vfork_child_exec_or_exit): Reset vfork parent's
vfork_child field before calling target_detach.

gdb/testsuite/ChangeLog:
2019-04-18  Tom de Vries  <tdevries@suse.de>
    Pedro Alves  <palves@redhat.com>

PR gdb/24454
* gdb.threads/vfork-follow-child-exec.c: New file.
* gdb.threads/vfork-follow-child-exec.exp: New file.
* gdb.threads/vfork-follow-child-exit.c: New file.
* gdb.threads/vfork-follow-child-exit.exp: New file.
gdb/infrun.c
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.threads/vfork-follow-child-exec.c [new file with mode: 0644]
gdb/testsuite/gdb.threads/vfork-follow-child-exec.exp [new file with mode: 0644]
gdb/testsuite/gdb.threads/vfork-follow-child-exit.c [new file with mode: 0644]
gdb/testsuite/gdb.threads/vfork-follow-child-exit.exp [new file with mode: 0644]