Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] Fix SIGTERM signal safety (PR gdb/15358)
Date: Thu, 25 Jul 2013 15:33:00 -0000	[thread overview]
Message-ID: <87txjivelx.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20130702200010.GA23478@host2.jankratochvil.net> (Jan	Kratochvil's message of "Tue, 2 Jul 2013 22:00:10 +0200")

>>>>> "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


  reply	other threads:[~2013-07-25 15:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-02 20:24 Jan Kratochvil
2013-07-25 15:33 ` Tom Tromey [this message]
2013-07-25 15:41   ` Jan Kratochvil
2013-07-25 19:07     ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87txjivelx.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox