X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 069EA385803F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1706885864;
	bh=vpx1ZcGMu83Y4f7kLeIUp2mi8rICRGEFRH8s3RXZ2As=;
	h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	 From;
	b=oFLOkQrbIODh6weA33SxtWltHYBO048ZC5ISoi8WYOluK0KNjjCtPSSHwcI75a4YO
	 604VZjKBqKucROv4D2MmGKXWwLnQQwA2HDlIb0Bo/gMPFEVY87aq1d7aSMwL3Ui0Kk
	 yKTXssU7mQE4wlqfQWZGsEC3GnMFvoURKwEz+r3w=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B373C3858403
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B373C3858403
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706885809; cv=none;
 b=UIU9/UN7lYglFhDLfvNcTLY7aNRlW7MCnL3BjFxj53jYBkfymzgB5lyQxgDa04CDqm10iQjsBeyrm390g0PrYtsP6btvX/9oCG5jqTgs3PC1ngsQjmh9jr+FvVisQK9vLIz2/VgQ5ekz+X3qytseB3LoGV2lSCv1TpY1me7gINo=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1706885809; c=relaxed/simple;
 bh=spEA/ZirmMpb+zSq837LIQqoMm01Ja68kRP9/4KfdBE=;
 h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;
 b=bq7CG9ZVQHhbC0xPNtsF+SIPqD92KV6yaIXHpy4FVJRGVORkqaISR+dxceQOJnuuFhqHUH0CN4qlJquqhdrGLuuO4q5JpMpf1v5nSTNDNJOYe68Eylsc/3VfQoZhhm4fZwFyyWyJIjRpWGrvaDIyTMKj4UAWouOQRcmvN+uyChI=
ARC-Authentication-Results: i=1; server2.sourceware.org
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1706885806; x=1707490606;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=EeIkITx4JP9F+da+ksb13X8hLO4bq47r7gQH2sTbjvE=;
 b=Emk5tkcmCSdewf9mtDjCnrbpyKLzpZGqAEsbiWDy7b2sH/pdQk6cKg8sGKg1d8b9M5
 XXcx+wMHzDnSvPBwQb4OvdMWzBbpBRqDsYcpWl00wwDYAlCn+SLle7n7UbWYMxhnXbQU
 2fnounQKj9mxKeWLdXnRTY0XM/1gYUt21aHoY9kHjARiykoO101zumu46Z4mc3SaOvyn
 JQz5SNZGEPG+8bgfcvAz9H1ngcfcK3NIotLNkIv111lgclsZ4GkPBvgk9KGzJ5DMCaJm
 iHgfHNq00Yxq73W5gQbftoX17bchpVwiAa8X38VPxW1fqtlAKmYSLicUGVxR8S3D94gA
 Gwzw==
X-Gm-Message-State: AOJu0Yz+dLpcgq0Tra0l76hfNlUCxTytdUiYKa0Xpq3lMO9roMR9a6ff
 sCR8yEGndiBJLsHRi4J2xsT6NV4DA+vuQgq3RcLNNeVswDyrjmrzht4Za/EZiYTWoM7etKxJF9a
 n/8fwY02uIqDSUHvS/cu6o6tcLe8FuzKU6LSBYhMtLqUipqIu
X-Google-Smtp-Source: AGHT+IGt0Oe/67EisGi2VwmPLAz3PvTp0au0YLqtKaOVA+htdxN/n4F5wQZhveoMJ6kvab4apYN2PeSmVqqIibhNPAs=
X-Received: by 2002:aa7:c984:0:b0:560:b00:440d with SMTP id
 c4-20020aa7c984000000b005600b00440dmr248219edt.13.1706885806376; Fri, 02 Feb
 2024 06:56:46 -0800 (PST)
MIME-Version: 1.0
References: <CAJQQdJiOEduFeAthZ+q+LNXV33aJOhAXqq3sCaxdCqRpAjVmvA AT mail DOT gmail DOT com>
 <CAB8Xom-PnumWSLoDFgERXA4GX0zotQiKFvi_wL7Bvsv133WAmw AT mail DOT gmail DOT com>
 <CAJQQdJhzSNZ5dG254g5dv_AuWRxt+R-HLdiCPTkCNv=o+4PVeQ AT mail DOT gmail DOT com>
 <ZbtsBD2IKYtH-duQ AT calimero DOT vinschen DOT de>
 <CAJQQdJhS3QgJe_KsfGof_6XM6cwtNRkbPQPR32-JaKCu8_8KEA AT mail DOT gmail DOT com>
 <ZbzmLRByzmDJxUcb AT calimero DOT vinschen DOT de>
 <16b354c2-bba4-40b8-8359-7eb9a79b3ee3 AT dronecode DOT org DOT uk>
 <CAJQQdJhYSkjGOFxF=-CnvBGgZa_Qv3HaH8nr8b3fjwqnizq3_Q AT mail DOT gmail DOT com>
 <Zbz5TGo_9rqkKMSp AT calimero DOT vinschen DOT de>
In-Reply-To: <Zbz5TGo_9rqkKMSp@calimero.vinschen.de>
Date: Fri, 2 Feb 2024 14:56:09 +0000
Message-ID: <CAJQQdJjurPUo_WfunkkXnraJrP57KUa0gTwSTUwT_mVpKTsLdg@mail.gmail.com>
Subject: Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error
 popups meant to be disabled in Cygwin?]
To: cygwin AT cygwin DOT com
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS,
 TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: David Allsopp via Cygwin <cygwin AT cygwin DOT com>
Reply-To: David Allsopp <david AT tarides DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
>
> On Feb  2 13:35, David Allsopp via Cygwin wrote:
> > Jon Turney via Cygwin wrote:
> >
> > > > I'm sympathetic, and personally I would prefer to revert the patch and
> > > > stick to SEM_FAILCRITICALERRORS by default.
> > > >
> > > > The question is this: Why does, apparently, everybody expect Cygwin to
> > > > do the "right thing", with different definitions of "right", when in
> > > > fact the executable in question can easily call SetErrorMode by itself?
> > >
> > > Yeah, if cygwin wasn't involved in the process ancestry, how would you
> > > get the behaviour you want?
> >
> > Ah, but that's how I hit this (and started digging further) -
> > precisely because the non-Cygwin program I'm using _has_ called
> > SetErrorMode and its direct calls to the faulty program _are_ doing
> > what's wanted (no popup dialog) but the calls which happen via Cygwin
> > are then torching that preference.
> >
> > Not really suggesting it be done this way (it feels more complicated
> > than just reverting the change), but in some ways perhaps Cygwin
> > should be using GetErrorMode on startup and instead of not inheriting
> > it, ensuring that it sets whatever it received? i.e. just before the
> > call to CreateProcess for a non-Cygwin binary, Cygwin restores the
> > error mode (for that thread only) to the value read at startup, calls
> > CreateProcess and then sets the error mode back.
>
> This sounds like a good ide, but...
>
> Is it actually a safe bet that the error mode set by SetThreadErrorMode
> is then propagated as process error mode to the child process?
>
> I have to ask that because Microsoft conveniently forgot to document
> this scenario in the MSDN docs.

:o) Never knowingly clear, are they! It would seem to be the intent of
SetThreadErrorMode that it would behave that way but who knows.

Happy to set up a quick experiment to check that it does work (i.e.
the invoked process has GetErrorMode set as expected) and that there's
no possible race between two threads in the calling process with
differing values (i.e. that having SEM_FAILCRITICALERRORS in one
thread and not in another behaves as expected. If it does appear to
work consistently, would you be willing to go down this route? Happy
to do the patch, although it'd be very helpful to have a couple of
pointers: I'm guessing the value would want to be captured just before
the one place where SetErrorMode is already called, but in which
structure should it then be stashed away to be reused in spawn?


David

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple