This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix SIGTERM signal safety (PR gdb/15358)


>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan>  void
Jan>  handle_sigterm (int sig)
Jan>  {
Jan>    signal (sig, handle_sigterm);
Jan> -  quit_force ((char *) 0, stdin == instream);
Jan> +
Jan> +  if (target_can_async_p ())
Jan> +    mark_async_signal_handler (async_sigterm_token);
Jan> +  else
Jan> +    {
Jan> +      sync_quit_force_run = 1;
Jan> +      set_quit_flag ();

I think calling set_quit_flag here may do the wrong thing in one case.

If Python is enabled, set_quit_flag sets a flag in the Python
interpreter.  This will cause a KeyboardInterrupt exception to be raised
if the Python interpreter happens to be the code checking the flag
first.

This means that Python would raise this exception, probably not what is
meant.  And then, since sync_quit_force_run is set, you'd still get the
quit_force call sometime after re-entering gdb anyhow.

It seems to me that simply not calling set_quit_flag ought to be safe
here.  QUIT checks the sync_quit_force_run already, so there doesn't
seem to be a need to set both flags.

I think this would fix the Python problem.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]