Re: [PATCH] PR gdb/30219: Clear sync_quit_force_run in quit_force

[Simon Marchi <simon.marchi@polymtl.ca>]

On 3/10/23 18:18, Kevin Buettner wrote:
> PR 30219 shows an internal error due to a "Bad switch" in
> print_exception() in gdb/exceptions.c.  The switch in question
> contains cases for RETURN_QUIT and RETURN_ERROR, but is missing a case
> for the recently added RETURN_FORCED_QUIT.  This commit adds that case
> in addition to introducing annotate_forced_quit() which will print a
> suitable annotation when annotations are turned on.
> 
> Making the above change allows the errant test case to pass, but does
> not fix the underlying problem, which I'll describe shortly.  Even
> though the addition of a case for RETURN_FORCED_QUIT isn't the actual
> fix, I still think it's important to add this case so that other
> situations which lead to print_exeption() being called won't generate
> that "Bad switch" internal error.
> 
> In order to understand the underlying problem, please examine
> this portion of the backtrace from the bug report:
> 
> 0x5576e4ff5780 print_exception
>         /home/smarchi/src/binutils-gdb/gdb/exceptions.c:100
> 0x5576e4ff5930 exception_print(ui_file*, gdb_exception const&)
>         /home/smarchi/src/binutils-gdb/gdb/exceptions.c:110
> 0x5576e6a896dd quit_force(int*, int)
>         /home/smarchi/src/binutils-gdb/gdb/top.c:1849
> 
> The real problem is in quit_force; here's the try/catch which
> eventually leads to the internal error:
> 
>   /* Get out of tfind mode, and kill or detach all inferiors.  */
>   try
>     {
>       disconnect_tracing ();
>       for (inferior *inf : all_inferiors ())
> 	kill_or_detach (inf, from_tty);
>     }
>   catch (const gdb_exception &ex)
>     {
>       exception_print (gdb_stderr, ex);
>     }
> 
> While running the calls in the try-block, a QUIT check is being
> performed.  This check finds that sync_quit_force_run is (still) set,
> causing a gdb_exception_forced_quit to be thrown.  The exception
> gdb_exception_forced_quit is derived from gdb_exception, causing
> exception_print to be called.  As shown by the backtrace,
> print_exception is then called, leading to the internal error.
> 
> The actual fix, also implemented by this commit, is to clear
> sync_quit_force_run along with the quit flag.  This will allow the
> various cleanup code, called by quit_force, to run without triggering
> a gdb_exception_forced_quit.  (Though, if another SIGTERM is sent to
> the gdb process, these flags will be set again and a QUIT check in the
> cleanup code will detect it and throw the exception.)

Clearing the quit flag sounds right.  However, I wonder if we should go
further and disable any "quitting" while GDB is in quit_force.  Meaning
that any SIGTERM or SIGINT received while in quit_force would have no
effect.  I don't know what good could be achieved by responding to a
SIGTERM or SIGINT while GDB is already in the process of cleaning up and
exiting.

What you have is fine with me for now though, it's a clear improvement
over the current situation.

> diff --git a/gdb/annotate.c b/gdb/annotate.c
> index 60fe6ccd5c2..36efce1af7c 100644
> --- a/gdb/annotate.c
> +++ b/gdb/annotate.c
> @@ -282,6 +282,13 @@ annotate_quit (void)
>      printf_unfiltered (("\n\032\032quit\n"));
>  }
>  
> +void
> +annotate_forced_quit (void)
> +{
> +  if (annotation_level > 1)
> +    printf_unfiltered (("\n\032\032forced-quit\n"));

Hmm, this in a new annotation?  In theory, this would need to be
documented, to have a NEWS entry, etc.  And then frontends using
annotations would need to be updated to use that.  We don't really want
that, if possible, given annotations are obsolete.

Would it work to display the "quit" annotation (the one printed by
annotate_quit)?  The doc [1] says, for that annotation:

  This annotation occurs right before GDB responds to an interrupt. 

and:

  Quit and error annotations indicate that any annotations which GDB was
  in the middle of may end abruptly. For example, if a
  value-history-begin annotation is followed by a error, one cannot
  expect to receive the matching value-history-end.

I think it also works in the forced quit case.  The execution of
whatever thing was going on is interrupted, just like in the regular
quit case, it just happens that GDB also happens to exit after that.

[1] https://sourceware.org/gdb/onlinedocs/annotate.html#Errors

Simon