[Bug breakpoints/13457] New: `catch syscall' doesn't work after `fork' is called

[Bug breakpoints/13457] New: `catch syscall' doesn't work after `fork' is called

[sergiodj at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13457

             Bug #: 13457
           Summary: `catch syscall' doesn't work after `fork' is called
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: breakpoints
        AssignedTo: unassigned@sourceware.org
        ReportedBy: sergiodj@redhat.com
    Classification: Unclassified


Given this simple example:

#include <stdio.h>
#include <unistd.h>

int
main (int argc, char **argv)
{
  if (fork () == 0)
    printf ("Child\n");
  chdir (".");
  return 0;
}


When a syscall catchpoint for `chdir' is inserted, GDB does not stop and the
program runs until the end.

However, if we set `follow-fork-mode' to `child', then the catchpoint triggers
correctly.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug breakpoints/13457] `catch syscall' doesn't work for parent after `fork' is called

[sergiodj at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13457

Sergio Durigan Junior <sergiodj at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|`catch syscall' doesn't     |`catch syscall' doesn't
                   |work after `fork' is called |work for parent after
                   |                            |`fork' is called

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug breakpoints/13457] `catch syscall' doesn't work for parent after `fork' is called

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13457

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #1 from Pedro Alves <palves at redhat dot com> 2012-10-24 16:17:46 UTC ---
Looking at confirming whether the issue is still present in current head, I
debugged this a little.

When handling the fork, we get here:

      /* Immediately detach breakpoints from the child before there's
     any chance of letting the user delete breakpoints from the
     breakpoint lists.  If we don't do this early, it's easy to
     leave left over traps in the child, vis: "break foo; catch
     fork; c; <fork>; del; c; <child calls foo>".  We only follow
     the fork on the last `continue', and by that time the
     breakpoint at "foo" is long gone from the breakpoint table.
     If we vforked, then we don't need to unpatch here, since both
     parent and child are sharing the same memory pages; we'll
     need to unpatch at follow/detach time instead to be certain
     that new breakpoints added between catchpoint hit time and
     vfork follow are detached.  */
      if (ecs->ws.kind != TARGET_WAITKIND_VFORKED)
    {
      /* This won't actually modify the breakpoint list, but will
         physically remove the breakpoints from the child.  */
      detach_breakpoints (ecs->ws.value.related_pid);
    }

Note this should be detaching breakpoints from the _child_ fork.
But we mess up, and "remove" the syscall catchpoint from the
parent (the current inferior):

(top-gdb) bt
#0  remove_catch_syscall (bl=0xea86f0) at ../../src/gdb/breakpoint.c:8036
#1  0x0000000000541d32 in remove_breakpoint_1 (bl=0xea86f0, is=mark_inserted)
at ../../src/gdb/breakpoint.c:3662
#2  0x000000000054196a in detach_breakpoints (ptid=...) at
../../src/gdb/breakpoint.c:3542
#3  0x00000000005b9011 in handle_inferior_event (ecs=0x7fffffffd3c0) at
../../src/gdb/infrun.c:3496

static int
remove_catch_syscall (struct bp_location *bl)
{
  struct syscall_catchpoint *c = (struct syscall_catchpoint *) bl->owner;
  struct inferior *inf = current_inferior ();
  struct catch_syscall_inferior_data *inf_data
    = get_catch_syscall_inferior_data (inf);

  --inf_data->total_syscalls_count;
  if (!c->syscalls_to_be_caught)
    --inf_data->any_syscall_count;

And so after the fork, we end up with the *_syscall_count's messed up in the
parent.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug breakpoints/13457] `catch syscall' doesn't work for parent after `fork' is called

[sergiodj at redhat dot com]

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

Sergio Durigan Junior <sergiodj at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at sourceware dot org   |sergiodj at redhat dot com

--- Comment #2 from Sergio Durigan Junior <sergiodj at redhat dot com> ---
This issue was apparently fixed by:

commit bd9673a4ded96ea5c108601501c8e59003ea1be6
Author: Philippe Waroquiers <philippe@sourceware.org>
Date:   Tue May 21 18:47:05 2013 +0000

I am checking if everything is correct, and will submit a testcase if
everything is OK.

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

[Bug breakpoints/13457] `catch syscall' doesn't work for parent after `fork' is called

[palves at redhat dot com]

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

--- Comment #3 from Pedro Alves <palves at redhat dot com> ---
While following the parent happened to get fixed by that patch, following the
child when we stay attached to the parent is not.  E.g.,

gdb -q ./testsuite/gdb.base/foll-fork -ex "set follow-fork child" -ex "set
detach-on-fork off"
Reading symbols from ./testsuite/gdb.base/foll-fork...done.
(gdb) catch fork
Catchpoint 1 (fork)
(gdb) r
Starting program: testsuite/gdb.base/foll-fork

Catchpoint 1 (forked process 2045), 0x00000033356bc87c in __libc_fork () at
../nptl/sysdeps/unix/sysv/linux/fork.c:130
130       pid = ARCH_FORK ();
(gdb) catch syscall
Catchpoint 2 (any syscall)
(gdb) c
Continuing.
[New process 2045]
[Inferior 2 (process 2045) exited normally]
(gdb) 


vs:


$ gdb -q ./testsuite/gdb.base/foll-fork -ex "set follow-fork child" -ex "set
detach-on-fork on"
...
Catchpoint 1 (forked process 2084), 0x00000033356bc87c in __libc_fork () at
../nptl/sysdeps/unix/sysv/linux/fork.c:130
130       pid = ARCH_FORK ();
(gdb) catch syscall 
Catchpoint 2 (any syscall)
(gdb) c
Continuing.
[New process 2084]

Catchpoint 2 (call to syscall exit_group), 0x00000033356bcaf9 in __GI__exit
(status=status@entry=0) at ../sysdeps/unix/sysv/linux/_exit.c:32
32            INLINE_SYSCALL (exit_group, 1, status);
(gdb) 


I'd be great if a test case exercised all variations of follow-fork parent/
child, detach-on-fork on/off.

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