DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52EA1r171170714
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 52EA1r171170714
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=Xd2lv3JD
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4932E3857810
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1741946511;
	bh=MBp58xe5KZ2EbkuAfvawr5rfGnXl/FUrn5xarzdqzCE=;
	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=Xd2lv3JDmKgnmamKeNs9+NifiWdS9l3qqNUAhWGVWonDTQuEP9a22U22Oo3lsrE6J
	 K8QcZuDN6l82UenQzURBj23QWlNye8vNaBpWNY3KBRqBkN/0T0sC5db+9G9nFOkcUf
	 VKgDdLsQpvgnljkCpJi0QOdjfEpw/8KCEwQbUMAI=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 532933858C48
Date: Fri, 14 Mar 2025 11:01:25 +0100
To: cygwin AT cygwin DOT com
Subject: Re: cygwin 3.6.0: No signals received after swapcontext() is used
Message-ID: <Z9P-dVoJi68Hr5yS@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
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>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20250314125632.dc61b5b087eb43d67228cc92@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 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?


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