Re: [PATCH 6/6] gdb: don't share aspace/pspace on fork with "detach-on-fork on" and "follow-fork-mode child"

[John Baldwin <jhb@FreeBSD.org>]

On 9/10/21 1:54 PM, Simon Marchi via Gdb-patches wrote:
> We found that when handling forks, two inferiors can unexpectedly share
> their program space and address space.  To reproduce:
> 
>   1. Using a test program that forks...
>   2. "set follow-fork-mode child"
>   3. "set detach-on-fork on" (the default)
>   4. run to a breakpoint somewhere after the fork
> 
> Step 4 should have created a new inferior:
> 
>      (gdb) info inferiors
>        Num  Description       Connection           Executable
>        1    <null>                                 /home/smarchi/build/wt/amd/gdb/fork
>      * 2    process 251425    1 (native)           /home/smarchi/build/wt/amd/gdb/fork
> 
> By inspecting the state of GDB, we can see that the two inferiors now
> share one program space and one address space:
> 
> Inferior 1:
> 
>      (top-gdb) p inferior_list.m_front.num
>      $2 = 1
>      (top-gdb) p inferior_list.m_front.aspace
>      $3 = (struct address_space *) 0x5595e2520400
>      (top-gdb) p inferior_list.m_front.pspace
>      $4 = (struct program_space *) 0x5595e2520440
> 
> Inferior 2:
> 
>      (top-gdb) p inferior_list.m_front.next.num
>      $5 = 2
>      (top-gdb) p inferior_list.m_front.next.aspace
>      $6 = (struct address_space *) 0x5595e2520400
>      (top-gdb) p inferior_list.m_front.next.pspace
>      $7 = (struct program_space *) 0x5595e2520440
> 
> You can then run inferior 1 again and the two inferiors will still
> erroneously share their spaces, but already at this point this is wrong.
> 
> The cause of the bad {a,p}space sharing is in follow_fork_inferior.
> When following the child and detaching from the parent, we just re-use
> the parent's spaces, rather than cloning them.  When we switch back to
> inferior 1 and run again, we find ourselves with two unrelated inferiors
> sharing spaces.
> 
> Fix that by creating new spaces for the parent after having moved them
> to the child.  My initial implementation created new spaces for the
> child instead.  Doing this breaks doing "next" over fork().  When "next"
> start, we record the symtab of the starting location.  When the program
> stops, we compare that symtab with the symtab the program has stopped
> at.  If the symtab or the line number has changed, we conclude the
> "next" is done.  If we create a new program space for the child and copy
> the parent's program space to it with clone_program_space, it creates
> new symtabs for the child as well.  When the child stop, but still on
> the fork() line, GDB thinks the "next" is done because the symtab
> pointers no longer match.  In reality they are two symtab instances that
> represent the same file.  But moving the spaces to the child and
> creating new spaces for the parent, we avoid this problem.
> 
> Note that the problem described above happens today with "detach-on-fork
> off" and "follow-fork-mode child", because we create new spaces for the
> child.  This will have to be addressed later.
> 
> Test-wise, improve gdb.base/foll-fork.exp to set a breakpoint that is
> expected to have a location in each inferiors.  Without the fix, when
> the two inferiors erroneously share a program space, GDB reports a
> single location.

So I wonder about the case where follow-fork-mode is parent and
detach-on-fork is off?  In that case, should the existing aspace/pspace
stay with the parent and the child get clones?  That is, using the
follow-fork-mode setting to determine which inferior gets the existing
aspace/pspace and assigning the cloned copies to the !follow-fork-mode
inferior?

-- 
John Baldwin