RE: Follow-fork-mode / detach-on-fork expected behavior?

["Breazeal, Don" <donb at codesourcery dot com>]

Hi
To make my questions below more palatable, I'll reframe them as a proposal for how follow-fork & detach-on-fork should work.  So, true or false:

When GDB is handling a fork,
(1) any process that is detached due to detach-on-fork should have all breakpoints and single step state removed (obvious)
(2) any process that is not detached should keep all the breakpoints and single-step state that originated in the parent - both the parent and child will have them
(3) after a process is detached due to detach-on-fork, it should not show up in the inferiors list (info inferiors)

If all three of these statements are true, then there are a couple of bugs related to this in native GDB, described below.  If that's the case I'll volunteer to look at them, but I'd like some agreement on what the desired behavior is before I commit time to that work.

Thanks
--Don

> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of Breazeal, Don
> Sent: Thursday, April 24, 2014 3:06 PM
> To: gdb@sourceware.org
> Subject: Follow-fork-mode / detach-on-fork expected behavior?
> 
> Hi
> 
> I'm working on implementation of follow-fork in gdbserver.  My intent is
> to make it work just like it works in native GDB.  However, I am
> confused by what looks like inconsistent behavior in native GDB.  I'm
> hoping to get some feedback on my observations so that I know how to
> proceed.  I want to make sure things are working in native GDB before
> going any further with gdbserver.
> 
> Apologies for the length of this email.  The only way I can think of to
> explain my questions is by describing what I see in a test case.  I'm
> using a test case that uses 'fork' (not 'vfork') in all-stop mode
> (gdb.base/foll-fork).  Aside from the fork mode settings, the commands
> are:
> (gdb) set verbose   # to see the fork msgs
> (gdb) break main
> (gdb) run
> (gdb) next 2        # this executes past the fork call
> 
> The behavior is inconsistent when following the child, depending on the
> setting for detach-on-fork.  Below is the behavior I see in the four
> possible combinations of fork settings after the 'next 2' command is
> entered, along with my specific questions:
> 
> 1) follow parent / detach child (default settings)
>   -  prints msg about detaching after fork
>   -  stops after the next command in the parent
>   -  one inferior left
> 
> 2) follow parent / don't detach child
>   -  prints [New process] msg
>   -  prints symbol reading/loading msgs
>   -  stops in parent after next
>   -  two inferiors left, info inferiors shows pids of both
> 
> So far, so good, this is what I expect.
> 
> 3) follow child / detach parent
>   -  prints msg about attach to child after fork
>   -  prints [New process] msg
>   -  prints [Switching to process ] msg
>   -  stops in child after 'next' command
>   -  two inferiors left, info inferiors shows parent 'null'
> 
> This looks like there might be a problem:
>   Q1: shouldn't there only be one inferior?
>   Q2: should the child have stopped?
> The manual doesn't make this completely clear.
> 
> 4) follow child / don't detach parent
>   -  prints msg about attach to child after fork
>   -  prints [New process] msg
>   -  prints symbol reading/loading msgs
>   -  child runs to completion
>   -  two inferiors left, info inferiors shows child 'null'
> 
> Something seems wrong here.
>   Q3: to be consistent, shouldn't the child process either have stopped
> after the 'next' command in both (3) and (4) or run to completion in
> both cases?
> 
> I'd appreciate it if someone could clarify the expected behavior for me,
> or if what I'm seeing is expected, explain the rationale.  If something
> needs to be fixed in the native implementation, I'll want to look at
> that before continuing with the remote case.
> Thanks
> --Don