DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 52ECs7J31338024
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 52ECs7J31338024
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=ni8crW7j
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 96A953857724
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1741956846;
	bh=twlnfDMrW2D4FT4EauNedIRlV1b07to9gu7E+4qBU6E=;
	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=ni8crW7jbbwale5s1gbi1ZLqOT0d/wygiFd1sa5YvO+paDbljDHTRC4eeucGAbsEM
	YnkhFODfjlVHFEtt1PM/8soQf+kB8R7Xs1AtO0k/E7c9w0NrAdOLR7ppQN+RbBNz0M
	5YsaPfc7Qspb60rBhcMnQPDvwKsMbVL/kS/wJVHk=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 107723857710
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org 107723857710
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741956765; cv=none;
	b=e4LGhVW5rH0gdG28FmN0UMmQAv87++rPAVodtVdBBYYE0RRfa+FaXYQ1aKPD1jO31r6SLVJbpuXQm9v7p+Y2Q2gQ6uEX2Eh743CmCD2cg4Pe7zGBGTM3eH3oE3YIe5PJ8JOG7m+2+ncmaF8BsGTp5ivHUY+Y0Td5SKKIb3G5x7Q=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1741956765; c=relaxed/simple;
	bh=ntmCQuMsNVnv6peEsGi09fvvtqSuukStTcxLBHcHHBI=;
	h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature;
	b=Irhd0VINJS1UXirSwYTuzuwgYkP5uij0KqO6A45EejFDUsiOg5GhVKXsXLOPE0RQtXZRoCkASTq48C8iy8srPZhBwjzpiHI2Km+M6q0NcKF/sLuoS1YcbSwwIJERWyG8G4GZwWQCmE6zZp+Z1Bf78+9/KtK9SRpesO4D35TGL/s=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 107723857710
Date:	Fri, 14 Mar 2025 21:52:42 +0900
To:	cygwin AT cygwin DOT com
Subject:	Re: cygwin 3.6.0: No signals received after swapcontext() is used
Message-Id:	<20250314215242.8ef1214b77ccc472139b3a3a@nifty.ne.jp>
In-Reply-To:	<Z9Qe0AqyIOwBxcc2@calimero.vinschen.de>
References:	<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>
	<20250314203548 DOT 878211c61777a8d99b7de7ea AT nifty DOT ne DOT jp>
	<Z9Qe0AqyIOwBxcc2 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 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!

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