From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57109 invoked by alias); 5 Aug 2016 00:08:44 -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 57090 invoked by uid 89); 5 Aug 2016 00:08:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,DATE_IN_PAST_03_06,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=baldwin, Baldwin, Hx-languages-length:1739, family X-HELO: bigwig.baldwin.cx Received: from bigwig.baldwin.cx (HELO bigwig.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 05 Aug 2016 00:08:33 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8DA0FB953; Thu, 4 Aug 2016 20:08:30 -0400 (EDT) From: John Baldwin To: gdb-patches@sourceware.org Cc: Pedro Alves Subject: Re: [PATCH] Fix PR gdb/18653: gdb disturbs inferior's inherited signal dispositions Date: Fri, 05 Aug 2016 00:08:00 -0000 Message-ID: <2148041.k6fglmTO5R@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <1470332251-10857-1-git-send-email-palves@redhat.com> References: <1470332251-10857-1-git-send-email-palves@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00084.txt.bz2 On Thursday, August 04, 2016 06:37:31 PM Pedro Alves wrote: > Today I was helping Phil debug something on the new C++ compile > support, and we noticed that when debugging gdb under gdb, the > inferior gdb behaved differently compared to when it was not being > debugged. Turned out to be a manifestation of PR gdb/18653. > > Since the exec family of functions do not reset the signal disposition > of signals that are set to SIG_IGN: > > http://pubs.opengroup.org/onlinepubs/7908799/xsh/execve.html > > Signals set to the default action (SIG_DFL) in the calling process > image are set to the default action in the new process > image. Signals set to be ignored (SIG_IGN) by the calling process > image are set to be ignored by the new process image. Signals set to > be caught by the calling process image are set to the default action > in the new process image (see ). > > gdb's (or gdbserver's) own signal handling should not interfere with > the signal dispositions their spawned children inherit. However, it > currently does. For example, some paths in gdb cause SIGPIPE to be > set to SIG_IGN, and as consequence, the child starts with SIGPIPE to > set to SIG_IGN too, even though gdb was started with SIGPIPE set to > SIG_DFL. > > In order to be transparent, when spawning new child processes to debug > (with "run", etc.), reset all signal dispositions back to what was > originally inherited from gdb/gdbserver's parent, just before execing > the target program to debug. Perhaps consider saving/restore the entire 'struct sigaction' instead of just the sa_handler field given you are already requiring sigaction? -- John Baldwin