From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107733 invoked by alias); 13 Nov 2018 22:37:55 -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 107724 invoked by uid 89); 13 Nov 2018 22:37:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=UD:mad-scientist.us, H*r:sk:gdb@sou, mad-scientist.us, madscientistus X-HELO: outbound-ss-579.bluehost.com Received: from outbound-ss-579.bluehost.com (HELO outbound-ss-579.bluehost.com) (74.220.218.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Nov 2018 22:37:52 +0000 Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 7A9391E09C3 for ; Tue, 13 Nov 2018 15:37:51 -0700 (MST) Received: from box5008.bluehost.com ([50.116.64.19]) by cmsmtp with ESMTP id MhJfgLbNDvdTuMhJfgcrBb; Tue, 13 Nov 2018 15:37:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mad-scientist.us; s=default; h=Content-Transfer-Encoding:Mime-Version: Content-Type:Date:To:Reply-To:From:Subject:Message-ID:Sender:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=qTQOjJ7UzUA1q2qDDiAqgFjS0QXKicT7mbZaFeQPrwU=; b=elujrWUTP4McmgBJcJR0t2uuP0 b187eFqSRQiVQw/bIN5hRvtpUBQbN4sZY/mEODRCZ15LO3IU5t4s2awGeOg3/tBy0PSr+R7Nxp7N9 CyD1bYJHQTCD6gNoY53gcb25i; Received: from [50.226.24.42] (port=42102 helo=pdslaptop) by box5008.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gMhJe-001WQH-V5 for gdb@sourceware.org; Tue, 13 Nov 2018 15:37:51 -0700 Message-ID: <8003dfcd98e9a4d1e43f53220e0d446669944ead.camel@mad-scientist.net> Subject: GDB (not) handling SIGINT...? From: Paul Smith Reply-To: paul@mad-scientist.net To: gdb@sourceware.org Date: Tue, 13 Nov 2018 22:37:00 -0000 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-11/txt/msg00002.txt.bz2 Hi all; I'm using GDB 8.1 on a modern 64bit GNU/Linux system (Ubuntu 18.04LTS). Recently I added a call to sigtimedwait() for SIGINT into my (multithreaded) program and now I'm having an issue with GDB. What I want is that if I attach to my program then continue, then use ^C at the GDB terminal, I should get a (gdb) prompt back but I do NOT want the SIGINT delivered to my program to wake up my sigtimedwait() call (because it will cause my program to do various things that I don't want it to do). I see that SIGINT is set to nopass: (gdb) info signals SIGINT Signal Stop Print Pass to program Description SIGINT Yes Yes No Interrupt but yet when I use ^C at the GDB prompt my sigtimedwait() call inside my program does return with "2" (SIGINT), which I don't want. I guess I don't understand what the docs mean when they say that the signal is not passed to the process under debug. Note that in my case I'm attaching to the program from a completely different terminal so there's no issue with process groups etc. and as far as I can understand it, the signal should only be delivered to GDB not my process, so unless there's some weird magic at work here it must be GDB forwarding that signal to my process. Anyone have any thoughts about this? Cheers!