From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51393 invoked by alias); 15 Nov 2018 16:24:40 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 51118 invoked by uid 89); 15 Nov 2018 16:24:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=killing, intercept X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Nov 2018 16:24:12 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3C96BC05D3EA; Thu, 15 Nov 2018 16:24:11 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 669FA60BE4; Thu, 15 Nov 2018 16:24:10 +0000 (UTC) Subject: Re: GDB (not) handling SIGINT...? To: paul@mad-scientist.net, Simon Marchi References: <8003dfcd98e9a4d1e43f53220e0d446669944ead.camel@mad-scientist.net> <17a7ce8aa190956bd7a8ba9bd7cdea16@polymtl.ca> <8b205cb2ff59c49ab9f4ad98564dfea3f5d1586d.camel@mad-scientist.net> Cc: gdb@sourceware.org From: Pedro Alves Message-ID: <276f4526-1873-0072-206c-c45bb47be3f6@redhat.com> Date: Thu, 15 Nov 2018 16:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <8b205cb2ff59c49ab9f4ad98564dfea3f5d1586d.camel@mad-scientist.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-11/txt/msg00007.txt.bz2 On 11/15/2018 03:51 PM, Paul Smith wrote: > On Thu, 2018-11-15 at 13:55 +0000, Pedro Alves wrote: >> #2 - If you attach to a process instead of running it from GDB, then ctrl-c >> reaches gdb first, and then GDB sends/forwards a SIGINT to the child process. > > To me this seems to be the problem. I've explicitly said I don't want > the signal passed to the process under debug (not a child process in > this situation right?)--in fact that's the default setting for SIGINT > --but yet GDB is still passing the signal along. > > Isn't that incorrect behavior? Not normally, because GDB is not really "passing" the signal. It's kill-ing the process with SIGINT, just like if you send a SIGINT from a separate terminal with "kill -INT $PID". Normally, ptrace (and thus gdb) intercepts the just-sent SIGINT _before_ the inferior ever sees it, and prints the "Program received signal SIGINT" message. At which point, the handle SIGINT pass/nopass settings come into effect, if the inferior is resumed again. The problem is that sigwait makes it so that ptrace does _not_ intercept that SIGINT. It's sigwait that is special. So that SIGINT that GDB sends thinking that ptrace will intercept it, is not intercepted, but does straight to the inferior. If your program was instead stopped in sleep(), then with "handle SIGINT nopass", the SIGINT would _not_ ever be passed to the inferior. Of course this means that to handle this, GDB's mechanism to interrupt the inferior needs to be different. Evidently kill'ing the inferior with SIGINT thinking that ptrace will intercept the SIGINT doesn't work in all cases. > > Is it there just for parity between the behavior of attaching to an > existing process versus running the process under GDB? Yeah, I think so. > I'd prefer it > work one way and not the other, rather than not work either way :). Yeah. :-) > > In my environment I'm _always_ attaching because our processes need to > be started through a separate service, or they don't have proper > security tokens to join the system. So it would work OK for me if just > the attached version behaved as expected. I get that others may have > different needs. With current GDB, you can work around this by attaching in non-stop mode ("set non-stop on"), and then using "continue&" to continue in the background, and the "interrupt" command to interrupt. In that mode, that command stops processes with SIGSTOP, not SIGINT. It's a lot more convenient with an IDE driving GDB than on the CLI, though. If you're OK with hacking GDB, s/SIGINT/SIGSTOP/g in child_pass_ctrlc should work reasonably OK, even though not perfect. Thanks, Pedro Alves