Re: [Regression] Segfault on native-extended-gdbserver + fork

[Pedro Alves <palves@redhat.com>]

On 01/28/2018 04:50 PM, Simon Marchi wrote:
> On 2018-01-28 01:32, Sergio Durigan Junior wrote:

> I'm fine with this, but I was curious about what happens in Pedro's multi-target branch.  I remember he said that the detach_inferior(int) version disappears in that branch, though I can't find where he said that.  But looking at the branch I can see it's indeed the case:
> 
>   https://github.com/palves/gdb/blob/palves/multi-target/gdb/inferior.c#L250
> 
> So I was wondering what remote_follow_fork calls in that case, since it can't call the detach_inferior(inferior *) version without an inferior.  Apparently it calls a new remote_detach_pid function:
> 
>   https://github.com/palves/gdb/blob/palves/multi-target/gdb/remote.c#L5859

remote_detach_pid is not new.  It exists in master.  What that url shows
is that I commented out the detach_inferior call in the branch.

Because in this case, we'd detaching a remote process that the core
of gdb never learned about.

> 
> This means (I just tried it) that it won't show the "[Inferior %d detached]\n" message in that case.  So what I would suggest is putting
> 
>   if (print_inferior_events)
>     printf_unfiltered (_("[Inferior %d detached]\n"), pid);
> 
> in its own function, called by both versions of detach_inferior for now (bonus, it de-duplicates the printing of the message).  In the multi-target branch, remote_target::follow_fork (renamed from remote_follow_fork) can call this function in the case where we don't have an inferior object.

But why would we want to print that?  We will have already printed

  "Detaching after fork from child process PID."

from the common code.  When native debugging, in this scenario,
we don't call detach_inferior either, right?  Can't see why
we'd want to call it for remote.

I think we should just remove that detach_inferior call, like in
the multi-target branch.

Thanks,
Pedro Alves