From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21856 invoked by alias); 4 Aug 2019 16:52:36 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 21848 invoked by uid 89); 4 Aug 2019 16:52:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=H*F:D*nl, near X-HELO: lb1-smtp-cloud8.xs4all.net Received: from lb1-smtp-cloud8.xs4all.net (HELO lb1-smtp-cloud8.xs4all.net) (194.109.24.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 04 Aug 2019 16:52:33 +0000 Received: from tmp.R8eiUj03b3 ([83.162.234.136]) by smtp-cloud8.xs4all.net with ESMTPSA id uJk9hwilyqTdhuJkAh7ty7; Sun, 04 Aug 2019 18:52:30 +0200 Date: Sun, 04 Aug 2019 16:52:00 -0000 Message-ID: From: Houder Reply-To: cygwin@cygwin.com To: cygwin@cygwin.com Subject: Re: Regression (last snapshot) References: <20190729134700.GO11632@calimero.vinschen.de> <20190729152327.GQ11632@calimero.vinschen.de> <20190729154049.GR11632@calimero.vinschen.de> <8e57d4da-722d-1b9a-bd28-5f96ed182f6a@cornell.edu> <0a09679b-1a0f-613b-04c8-1a63da8a00c2@cornell.edu> <33aead20-540c-ee3b-0d38-ff053fbac040@dronecode.org.uk> <12269538-c387-1f1e-ab5a-b36b60d09937@cornell.edu> <20190801160440.GC11632@calimero.vinschen.de> <19e73527-cb9a-a106-a57a-2895b8a520c9@cornell.edu> In-Reply-to: Content-Type: text/plain; charset=UTF-8; format=fixed User-Agent: mua.awk 0.99 X-SW-Source: 2019-08/txt/msg00048.txt.bz2 On Fri, 2 Aug 2019 14:34:02, Ken Brown wrote: > I think I've finally got it. > > First of all, here's what POSIX says about signal handlers after an exec: > > "Signals set to the default action (SIG_DFL) in the calling process > image shall be set to the default action in the new process image. > Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the calling > process image shall be set to be ignored by the new process image. > Signals set to be caught by the calling process image shall be set to > the default action in the new process image (see )." > > Second, here's a quote from the GTK+ documentation for gtk_init(): > > "Since 2.18, GTK+ calls signal (SIGPIPE, SIG_IGN) during initialization, > to ignore SIGPIPE signals, since these are almost never wanted in > graphical applications. If you do need to handle SIGPIPE for some > reason, reset the handler after gtk_init(), but notice that other > libraries (e.g. libdbus or gvfs) might do similar things." > > Third, xwin-xdg-menu calls gtk_init() near the beginning of main(). > > Putting this all together, Eric's explanation is indeed correct. All > processes created by xwin-xdg-menu via fork/exec inherit the property of > ignoring SIGPIPE. > > I don't know if this is a bug, but it certainly leads to surprising > behavior. Jon, maybe xwin-xdg-menu needs to call signal(SIGPIPE, > SIG_DFL) either after calling gtk_init() or before calling exec()? Another option? - https://bugs.python.org/issue1652 - see msg115364 (Author: Mitar) # GHC Haskell compiler is currently opting for a different solution: # installing an default empty handler which is cleared by exec # automatically and signal handler is restored back to SIG_DFL: # # http://hackage.haskell.org/trac/ghc/ticket/4274 Installing the empty handler after the call to gtk_init() ... Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple