DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52EEJCbR1425623
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 52EEJCbR1425623
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=Uet5Yh6Z
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1B86A3857710
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1741961950;
	bh=YXmPTQ6xaBO2lHXVQETBRxgXin9o548K3FZ7W9mlA1I=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=Uet5Yh6ZJx8yoah+Y9USYHlctqKwPHAZAEWgMMajCO2rgGNWB83jd0aJxkliXpUUv
	 A2mrbJOG/I+QNRdTVtxJK7NhmhbtbVnFPNaWh77FMj/K/B6NhhBydPL9+YgcxQXlgk
	 JaCZrZ5UuMswZOnYzdOR2CLy8NpCUDyfrgTylA/8=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 123BA3858C48
Date: Fri, 14 Mar 2025 15:18:45 +0100
To: cygwin AT cygwin DOT com
Subject: Re: cygwin 3.6.0: No signals received after swapcontext() is used
Message-ID: <Z9Q6xVN3HhLd88dv@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <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>
 <20250314203548 DOT 878211c61777a8d99b7de7ea AT nifty DOT ne DOT jp>
 <Z9Qe0AqyIOwBxcc2 AT calimero DOT vinschen DOT de>
 <20250314215242 DOT 8ef1214b77ccc472139b3a3a AT nifty DOT ne DOT jp>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20250314215242.8ef1214b77ccc472139b3a3a@nifty.ne.jp>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
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: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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 Mar 14 21:52, Takashi Yano via Cygwin wrote:
> On Fri, 14 Mar 2025 13:19:28 +0100
> Corinna Vinschen wrote:
> > On Mar 14 20:35, Takashi Yano via Cygwin wrote:
> > > On Fri, 14 Mar 2025 11:01:25 +0100
> > > Corinna Vinschen wrote:
> > > > 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.
> > 
> > Good point.  I attach a new proposal.  It also doesn't check against
> > &initialized (becasue that doesn't avoid an overflow into initialized,
> > but against the last slot of the stack.  This also moves pop into
> > the C++ code and drops its assembler counterpart.
> > 
> > Ok?
> 
> LGTM. Thanks!

Pushed.  I didn't create a test release, because I was sure you
would push your other signal patches ASAP anyway.


Thanks,
Corinna

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