Re: [PATCH 2/2] gdb/remote: return early from remote_check_symbols if waiting for stop reply

[Pedro Alves <pedro@palves.net>]

On 2022-04-24 04:20, Simon Marchi via Gdb-patches wrote:

> What happens is:
> 
>  - After doing the "continue" on inferior 1, the remote target gives us
>    a VFORK_DONE event.  The core ignores it and resumes inferior 1.
>  - Since prune_inferiors is now called after each handled event, in
>    fetch_inferior_event, it is called after we handled that VFORK_DONE
>    event and resumed inferior 1.
>  - Inferior 2 is pruned, which (see backtrace above) causes its program
>    space to be deleted, which clears the symtabs for that program space,
>    which calls the new_objfile observable and remote_new_objfile
>    observer (with a nullptr objfile, to indicate that the previously
>    loaded symbols have been discarded), which calls
>    remote_check_symbols.
> 
> remote_check_symbols is the function that sends the qSymbol packet, to
> let the remote side ask for symbol addresses.  The problem is that the
> remote target is working in all-stop / sync mode and is currently
> resumed.  It has sent a vCont packet to resume the target and is waiting
> for a stop reply.  It can't send any packets in the mean time.  That
> causes the exception to be thrown.

The inferiors that are pruned, their corresponding processes are gone, otherwise
they wouldn't be pruned.  So it seems wrong to even send a qSymbol packet at all,
as qSymbol on the remote end will be interpreted as "new symbols in the current process",
and the remote current process will have nothing to do with the pruned inferior.

Note this comment and target_has_execution check:

 /* Symbol look-up.  */

 void
 remote_target::remote_check_symbols ()
 {
   char *tmp;
   int end;

   /* The remote side has no concept of inferiors that aren't running
      yet, it only knows about running processes.  If we're connected
      but our current inferior is not running, we should not invite the
      remote target to request symbol lookups related to its
      (unrelated) current process.  */
   if (!target_has_execution ())
     return;

So if we're getting past this check, it seems to me that this means that we're calling
remote_check_symbols in the context of some other inferior other than the one that
is being pruned, which seems to be to be the bug here.

Note a bit below that function does:

  /* Make sure the remote is pointing at the right process.  Note
     there's no way to select "no process".  */
  set_general_process ();

... again, this is going to set the remote focus on gdb's current inferior,
but that inferior has no relation to the inferior that was pruned, so the
remote end is going to be querying symbols for a process that hasn't
really changed its symbols.

> 
> This wasn't a problem before, when prune_inferiors was called in
> normal_stop, because it was always called at a time the target was not
> resumed.
> 
> I realized there are simpler ways to trigger this problem.  You only
> need to load a symbol file (which triggers remote_check_symbols) while
> sync execution is ongoing:
> 
>     $ ./gdb -q --data-directory=data-directory -nx a.out \
>           -ex "tar ext :1234" \
> 	  -ex "tb main" \
> 	  -ex c \
> 	  -ex "c&" \
> 	  -ex "add-inferior" \
> 	  -ex "inferior 2" \
> 	  -ex "file /bin/ls"
>     * aborts because of the same exception *
> 

This is a valid problem, but a different problem, IMO.