DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 52EBajWc1246177
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 52EBajWc1246177
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=qNVwfmse
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org B01293857B98
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1741952203;
	bh=0NolmtCFzLU8+CBczjkBNnHZgE16N0iuoiZBSK/LRQc=;
	h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=qNVwfmsehxDK8I4GwCE76ob2AxgSHloHVnoqprZ9bfspHoC1+rAu9DXx8R4mHbeYK
	D7dU9SYDRNzf0NspiHDgUQAo74aX5e480VxMtxdsBYwA3APBL7i5KvIZg5hPHGUwMO
	sAG3dZoCXvCi24IMpAHtTwEIp5ZgUGYVPtQaYVSs=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org EC43C3858C52
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org EC43C3858C52
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741952155; cv=none;
	b=sAOgTTtB4GNSyDg79KBG9SUjuPMEGwi5qwDv1+5+otYU0L4IDbttysrSjqjIETAXc18QZ+ycFwLR2phmd1HbesHlIpntsdKdsjnNJ5cGFPuMfPzLlK9WosLsdQVW87v/KXHm82KcHbPsZTvElqI9hZUyNH66XXoIwY3EchevilM=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1741952155; c=relaxed/simple;
	bh=fcB8DFh2Gq6hPdwLBSKHwU13dASpJ5vqhq0DQeYFXIk=;
	h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature;
	b=hB9Wj83XglUAeg1IfJbVR5AMgSyiTy5sSNN89sUICcA5fL1NoyRd4iZt2hrI8Rh/J0is0PXdbp/l7+jJjvxzIfZPlFfu8Pzjx3vLe91KPpcR/VmEnO+zhoZB4EeOzTrAL9SenvOXIQzJAQ9ZIpW/RD/BrIbj9goLnbhyxNQcMNo=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org EC43C3858C52
Date:	Fri, 14 Mar 2025 20:35:48 +0900
To:	cygwin AT cygwin DOT com
Subject:	Re: cygwin 3.6.0: No signals received after swapcontext() is used
Message-Id:	<20250314203548.878211c61777a8d99b7de7ea@nifty.ne.jp>
In-Reply-To:	<Z9P-dVoJi68Hr5yS@calimero.vinschen.de>
References:	<Z9Gooi9C1UcJBuMW AT calimero DOT vinschen DOT de>
	<Z9Gw6inr56cd4TGe AT calimero DOT vinschen DOT de>
	<Z9G1BBjghen0kWvx AT calimero DOT vinschen DOT de>
	<c0000d72-2b39-2647-648f-9006bed1273e AT t-online DOT de>
	<20250313204252 DOT e340f0de50838f161b0e8323 AT nifty DOT ne DOT jp>
	<20250313213148 DOT 6c2cb65f5e692005f28d3d2c AT nifty DOT ne DOT jp>
	<Z9MIKWFS1q-TYojK AT calimero DOT vinschen DOT de>
	<Z9NgWcJyt9kS5lCG AT calimero DOT vinschen DOT de>
	<20250314081236 DOT bbdb1da7d746745925cdc752 AT nifty DOT ne DOT jp>
	<20250314125632 DOT dc61b5b087eb43d67228cc92 AT nifty DOT ne DOT jp>
	<Z9P-dVoJi68Hr5yS AT calimero DOT vinschen DOT de>
X-Mailer:	Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
Mime-Version:	1.0
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-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
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:	Takashi Yano via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
Errors-To:	cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

On Fri, 14 Mar 2025 11:01:25 +0100
Corinna Vinschen wrote:
> On Mar 14 12:56, Takashi Yano via Cygwin wrote:
> > On Fri, 14 Mar 2025 08:12:36 +0900
> > Takashi Yano wrote:
> > > On Thu, 13 Mar 2025 23:46:49 +0100
> > > Corinna Vinschen wrote:
> > > > I have a slighty changed version. This one treats anything other
> > > > than 0, 1 or 2 new addresses on the stack as bug.  I really made
> > > > an effort trying to come up with a situation where the signal
> > > > stack underflows, but I just couldn't.  If I'm missing something,
> > > > please explain how this may happen.
> > > > 
> > > > Apart from that, I attached my patch proposal.
> > > 
> > > I think the following is the right thing. This version pulls return
> > > addresses completely (not only one) before calling signal handler.
> > > I think, stackptr - orig_stackptr can be larger than 2 when
> > > user code
> > >   signal handler 1
> > >     signal handler 2
> > >       signal handler 3
> > >         signal handler 4
> > >         ret
> > >       ret
> > >     ret
> > >   HERE <= stackptr - orig_stackptr == 3
> > >   ret
> > > Is this right?
> > 
> > No, I was wrong. Every time when call_signal_handler() is
> > called, the _cygtls::stack is pulled, so, it always becomes
> > empty. Therefore, stackptr - orig_stackptr is never more
> > than two.
> > 
> > So, _cygtls::stack needs only two spaces maximum. Please
> > look attached v2 patch. Do I overlook something?
> 
> I don't think so.  I was mulling in circles over this tonight
> (don't ask me how I slept!) and came to the same conclusion.
> But here's the problem:
> 
> I'm simply not 100% sure.
> 
> What concerns me is that stackptr points beyond stack if the stack
> is full (i.e., sigdelayed + return address).
> 
> That was what happened before I applied a942476236b5: stackptr was
> incremented until it pointed at _cygtls::initialized, and eventually it
> overwrote it.  Fortunately, that stopped further incrementing due to the
> isinitialized() test.
> 
> So, if there *is* a twisted situation which results in pushing another
> return address onto the stack, a stack size of 2 would again result in
> initialized being overwritten.  So I wonder if we should keep kind of
> an airbag for an unusual situation.  Plus trying to keep stackptr inside
> stack even if it's full.  So that stackptr never grows into initialized:
> 
>   #define TLS_STACK_SIZE 5
> 
> and
> 
>     void push (__tlsstack_t addr)
>     {
>       if (stackptr < (__tlsstack_t *) &initialized)
> 	*stackptr++ = (__tlsstack_t) addr;
>     }
> 
> What do you think?

Yeah. We do not have to minimize the stack space at the cost of
taking risks.

One more thing. I am also concerned that pop() lacks a guard.
If pop() calls when stack is empty, then push() destroys the
stackptr pointer value.

-- 
Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>

-- 
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

- Raw text -