From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5220 invoked by alias); 25 Jul 2013 15:33:40 -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 5197 invoked by uid 89); 25 Jul 2013 15:33:40 -0000 X-Spam-SWARE-Status: No, score=-5.4 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:33:39 +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 r6PFXVfo007049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 25 Jul 2013 11:33:31 -0400 Received: from barimba (ovpn-113-128.phx2.redhat.com [10.3.113.128]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r6PFXUcr017980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 25 Jul 2013 11:33:30 -0400 From: Tom Tromey To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [patch] Fix SIGTERM signal safety (PR gdb/15358) References: <20130702200010.GA23478@host2.jankratochvil.net> Date: Thu, 25 Jul 2013 15:33:00 -0000 In-Reply-To: <20130702200010.GA23478@host2.jankratochvil.net> (Jan Kratochvil's message of "Tue, 2 Jul 2013 22:00:10 +0200") Message-ID: <87txjivelx.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-07/txt/msg00620.txt.bz2 >>>>> "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. 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