This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix SIGTERM signal safety (PR gdb/15358)
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 25 Jul 2013 09:33:30 -0600
- Subject: Re: [patch] Fix SIGTERM signal safety (PR gdb/15358)
- References: <20130702200010 dot GA23478 at host2 dot jankratochvil dot net>
>>>>> "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