DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52BBYWVc3238253
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E85E4385840E
Subject: Re: cygwin 3.6.0: No signals received after swapcontext() is used
To: cygwin AT cygwin DOT com
References: <ec6e2050-953f-0d47-c385-cfa598566291 AT t-online DOT de>
 <Z8nxYCxthcsMVqzL AT calimero DOT vinschen DOT de>
 <bf4eb7e1-66e3-e1f9-67e2-c4d4a75ff6c8 AT t-online DOT de>
 <Z864NNIyYwOWk5I3 AT calimero DOT vinschen DOT de>
Message-ID: <373993a3-9f0f-9750-60a0-950f83b3b0b5@t-online.de>
Date: Tue, 11 Mar 2025 12:32:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101
 SeaMonkey/2.53.20
MIME-Version: 1.0
In-Reply-To: <Z864NNIyYwOWk5I3@calimero.vinschen.de>
Content-Type: multipart/mixed; boundary="------------37B20CB5E30AE712CBFA874C"
Precedence: list
From: Christian Franke via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Christian Franke <Christian DOT Franke AT t-online DOT de>
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>

This is a multi-part message in MIME format.
--------------37B20CB5E30AE712CBFA874C
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Corinna Vinschen via Cygwin wrote:
> On Mar  8 12:07, Christian Franke via Cygwin wrote:
>> ...
>> This is possibly a regression introduced in 3.0.6. A comparison of strace
>> outputs of signal handling before and after the swapcontext() calls reveals
>> that 'incyg' is incorrectly set after swapcontext(). A revert of
>>    https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=c5f9eed1
>> fixes both the testcase and 'stress-ng --context ...'.
> Ahhh, good point.  When I looked into get/setcontext last week, I was
> wondering about this _my_tls.incyg = true, but didn't look into the
> history.
>
> I'm not sure if this was the right thing to do anyway.  Unfortunately,
> my commit message of the time was really really bad, and I don't see
> anything in the mailing lists pointing out where the idea to set iscyg
> was coming from.
>
> In the light of the signal changes in Cygwin, it might be a good idea to
> drop it.
>
>> No patch provided because I'm not sure how to handle the (at least) two
>> other use cases of setcontext() correctly:
>> - the call from _cygtls::call_signal_handler(), and
> I re-read the POSIX and Linux man pages on sigaction.  None of them
> claim that the context given to the signal handler is anything other
> than read-only information given to the handler, and, worse, supposed
> to be used by the signal mechanism after the signal handler returns.
>
> So it seems calling setcontext() on the vague notion that the signal
> handler expects this if it changed the context, was a bug from the start.
>
> I'm inclined to apply this patch:
>
> diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
> index 6d8985374b9e..a05883e3fc4f 100644
> --- a/winsup/cygwin/exceptions.cc
> +++ b/winsup/cygwin/exceptions.cc
> @@ -1850,14 +1850,6 @@ _cygtls::call_signal_handler ()
>   					? context.uc_sigmask : this_oldmask);
>         if (this_errno >= 0)
>   	set_errno (this_errno);
> -      if (this_sa_flags & SA_SIGINFO)
> -	{
> -	  /* If more than just the sigmask in the context has been changed by
> -	     the signal handler, call setcontext. */
> -	  context_copy.uc_sigmask = context.uc_sigmask;
> -	  if (memcmp (&context, &context_copy, sizeof context) != 0)
> -	    setcontext (&context);
> -	}
>       }
>   
>     /* FIXME: Since 2011 this return statement always returned 1 (meaning
> @@ -1899,7 +1891,6 @@ setcontext (const ucontext_t *ucp)
>   {
>     PCONTEXT ctx = (PCONTEXT) &ucp->uc_mcontext;
>     set_signal_mask (_my_tls.sigmask, ucp->uc_sigmask);
> -  _my_tls.incyg = true;
>     RtlRestoreContext (ctx, NULL);
>     /* If we got here, something was wrong. */
>     set_errno (EINVAL);
>
> It's not quite clear to me why signal handling should be broken if
> setcontext is used inside a signal handler.  The incyg flag is false
> when running the signal handler and that's correct.  Theoretically a
> running signal handler is not different from other process code.
>
> Do you have an STC, by any chance?

The attached testcase should test the following use cases of setcontext:
- call from regular user space
- call from a signal handler interrupting user space
- call from a signal handler interrupting a system call

It works as expected ... until the signal count reaches 256. Then 
signals are again only delivered from inside of a system call.

$ uname -r
3.6.0-0.427.g1d97f8aa4385.x86_64

$ gcc -o ctxloop ctxloop.c

$ ./ctxloop # and then press+hold ^C
0x0: sigcnt=0
0x7ffffcc40: main
0x7ffffcbb0: waste_time
[SIGINT]
0x7ffffc4c0: sigcnt=1
0x7ffffcc40: main
0x7ffffcbb0: waste_time
[SIGINT]
0x7ffffc440: sigcnt=2
0x7ffffcc40: main
0x7ffffcbb0: waste_time
[SIGINT]
0x7ffffc440: sigcnt=3
0x7ffffcc40: main
0x7ffffcbb0: waste_time
[SIGINT]
0x7ffffc400: sigcnt=4
0x7ffffcc40: main
0x7ffffcbb0: waste_time
...
[SIGINT]
0x7ffffc400: sigcnt=255
0x7ffffcc40: main
0x7ffffcbb0: waste_time
[SIGINT]
0x7ffffc400: sigcnt=256
0x7ffffcc40: main
0x7ffffcbb0: waste_time
[^C][^C][^C]
<return> to continue, 'q' to quit
[SIGINT]
0x7ffffc630: sigcnt=257
0x7ffffcc40: main
0x7ffffcbb0: waste_time
[^C][^C][^C]
<return> to continue, 'q' to quit
[SIGINT]
...

Interesting... Hmm... is there some 8-bit counter which overflows and 
then stucks at 0xff or 0x00?

-- 
Regards,
Christian


--------------37B20CB5E30AE712CBFA874C
Content-Type: text/plain; charset=UTF-8;
 name="ctxloop.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="ctxloop.c"

I2luY2x1ZGUgPG1hdGguaD4NCiNpbmNsdWRlIDxzaWduYWwuaD4NCiNpbmNsdWRlIDxzdGRp
by5oPg0KI2luY2x1ZGUgPHVjb250ZXh0Lmg+DQojaW5jbHVkZSA8dW5pc3RkLmg+DQoNCnN0
YXRpYyB1Y29udGV4dF90IHVjdHg7DQpzdGF0aWMgdm9sYXRpbGUgc2lnX2F0b21pY190IHNp
Z2NudDsNCnN0YXRpYyB2b2xhdGlsZSB2b2lkKiBzaWdmcmFtZTsNCg0Kc3RhdGljIHZvaWQg
c2lnaGFuZGxlcihpbnQgc2lnKQ0Kew0KICAodm9pZClzaWc7DQogICsrc2lnY250Ow0KICBz
aWdmcmFtZSA9IF9fYnVpbHRpbl9mcmFtZV9hZGRyZXNzKDApOw0KICB3cml0ZSgxLCAiW1NJ
R0lOVF1cbiIsIDkpOw0KICBpZiAoc2V0Y29udGV4dCgmdWN0eCkpIC8vIGdvdG8gbG9vcDsN
CiAgICB3cml0ZSgxLCAiW0ZBSUxdXG4iLCA3KTsNCn0NCg0Kc3RhdGljIHZvaWQgX19hdHRy
aWJ1dGVfXyAoKG5vaW5saW5lKSkgd2FzdGVfdGltZSgpDQp7DQogIHByaW50ZigiJXA6IHdh
c3RlX3RpbWVcbiIsIF9fYnVpbHRpbl9mcmFtZV9hZGRyZXNzKDApKTsNCiAgdm9sYXRpbGUg
ZG91YmxlIHggPSAxLjA7DQogIGNvbnN0IGludCBuID0gNDUqMTAwMCoxMDAwOyAvLyB+Mi41
cyBvbiBpNy0xNDcwMA0KICBmb3IgKGludCBpID0gMDsgaSA8IG47IGkrKykNCiAgICB4ID0g
YXNpbihzaW4oeCkpOw0KfQ0KDQppbnQgbWFpbigpDQp7DQogIHNpZ25hbChTSUdJTlQsIHNp
Z2hhbmRsZXIpOw0KICBpZiAoZ2V0Y29udGV4dCgmdWN0eCkpIHsgLy8gbG9vcDoNCiAgICBw
ZXJyb3IoImdldGNvbnRleHQiKTsgcmV0dXJuIDE7DQogIH0NCiAgcHJpbnRmKCIlcDogc2ln
Y250PSVkXG4iLCBzaWdmcmFtZSwgc2lnY250KTsNCiAgcHJpbnRmKCIlcDogbWFpblxuIiwg
X19idWlsdGluX2ZyYW1lX2FkZHJlc3MoMCkpOw0KDQogIHdhc3RlX3RpbWUoKTsgLy8gU0lH
SU5UIGhpdHMgdXNlciBzcGFjZQ0KDQogIHByaW50ZigiPHJldHVybj4gdG8gY29udGludWUs
ICdxJyB0byBxdWl0XG4iKTsNCiAgY2hhciBidWZbODBdOw0KICBpbnQgbnIgPSByZWFkKDEs
IGJ1Ziwgc2l6ZW9mKGJ1ZikpOyAvLyBTSUdJTlQgaGl0cyAia2VybmVsIiBzcGFjZQ0KICBp
ZiAobnIgPiAwICYmIGJ1ZlswXSA9PSAncScpDQogICAgcmV0dXJuIDA7DQogIGlmIChuciA9
PSAtMSkNCiAgICBwZXJyb3IoInJlYWQiKTsNCg0KICBzZXRjb250ZXh0KCZ1Y3R4KTsgLy8g
Z290byBsb29wOw0KICBwZXJyb3IoInNldGNvbnRleHQiKTsNCiAgcmV0dXJuIDE7DQp9DQo=
--------------37B20CB5E30AE712CBFA874C
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


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

--------------37B20CB5E30AE712CBFA874C--