From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22003 invoked by alias); 25 Jul 2013 15:41:07 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 21994 invoked by uid 89); 25 Jul 2013 15:41:07 -0000 X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 25 Jul 2013 15:41:06 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6PFewIp008566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 25 Jul 2013 11:40:59 -0400 Received: from host2.jankratochvil.net (ovpn-116-19.ams2.redhat.com [10.36.116.19]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r6PFetKg022901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 25 Jul 2013 11:40:57 -0400 Date: Thu, 25 Jul 2013 15:41:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [patch] Fix SIGTERM signal safety (PR gdb/15358) Message-ID: <20130725154054.GA22227@host2.jankratochvil.net> References: <20130702200010.GA23478@host2.jankratochvil.net> <87txjivelx.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87txjivelx.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-07/txt/msg00621.txt.bz2 On Thu, 25 Jul 2013 17:33:30 +0200, Tom Tromey wrote: > >>>>> "Jan" == Jan Kratochvil 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. This is SIGTERM. We do not care much what happens with GDB, we just need to ensure GDB does not crash and that GDB removes breakpoints from the inferior. I am roughly aware it may somehow abort Python scripts but IMO that is what we want to do. > 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. Without aborting Python the Python code may run for too long before QUIT; may get checked again back in GDB. > I think this would fix the Python problem. Could you be more specific what is the Python problem? It is expected SIGTERM is not a nice signal. Thanks, Jan