Recent testsuite/winsup.api/pthread/cancel2 failure

[Takashi Yano]

On Mon, 22 Dec 2025 23:04:50 +0900
Takashi Yano wrote:
> On Wed, 17 Dec 2025 19:37:37 +0900
> Takashi Yano wrote:
> > Hi Jon,
> > 
> > Thanks for the reply.
> > 
> > On Tue, 16 Dec 2025 13:11:15 +0000
> > Jon Turney wrote:
> > > On 14/12/2025 07:39, Takashi Yano via Cygwin wrote:
> > > > On Sun, 14 Dec 2025 16:26:37 +0900
> > > > Takashi Yano via Cygwin <cygwin@cygwin.com> wrote:
> > > > 
> > > >> Recently, I have concerned that testsuite winsup.api/pthread/cancel2 fails
> > > >> consistently.
> > > >>
> > > >> https://github.com/cygwin/cygwin/actions/runs/19926408142/job/57127200619
> > > 
> > > Thanks very much for looking into this!
> > > 
> > > I have the vague idea that this problem started showing up (more?) when 
> > > the CI VM was upgraded from Windows Server 2022 to Windows Server 2025, 
> > > but I guess that's maybe just timings...
> > 
> > IIRC, this did not happen when I uses Win10. Now, I'm using Win11.
> > 
> > > >> I'm not sure why this happens, but it also falis in my local environment.
> > > >> I looked into this issue a bit, and found that access violation happnes
> > > >> in CloseHandle() in _cygtls::remove().
> > > >>
> > > >> And I am also not sure why at all, cancel2 works if CloseHandle()'s are
> > > >> replaced with NtClose() as follows.
> > > 
> > > I think this is just the difference between the two calls: CloseHandle 
> > > generates an exception whereas NtClose returns an error code if the 
> > > handle is invalid.
> > > 
> > > Doesn't really explain whats wrong with the handle, though.
> > 
> > I checked the return code of NtClose() and found the it is STATUS_SUCCESS.
> > If the handle is invalid, NtClose() returns error code, I think...
> 
> I worked on this issue, and found the following code solves the issue,
> without "CloseHandle()/NtClose()" patch.
> 
> diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
> index 86a00e76e..82d52f44f 100644
> --- a/winsup/cygwin/thread.cc
> +++ b/winsup/cygwin/thread.cc
> @@ -630,6 +630,8 @@ pthread::cancel ()
>        threadlist_t *tl_entry = cygheap->find_tls (cygtls);
>        if (!cygtls->inside_kernel (&context))
>  	{
> +	  *(ULONG_PTR *) context._CX_stackPtr = context._CX_instPtr;
> +	  context._CX_stackPtr -= sizeof (ULONG_PTR);
>  	  context._CX_instPtr = (ULONG_PTR) pthread::static_cancel_self;
>  	  SetThreadContext (win32_obj_id, &context);
>  	}
> 
> But, I'm not sure why at all.
> 
> pthread::static_cancel_self() never returns, so stack should not affect,
> I think.
> 
> Any idea?

Alignment issue?

This might be the right thing.

diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
index 86a00e76e..ec1e3c98c 100644
--- a/winsup/cygwin/thread.cc
+++ b/winsup/cygwin/thread.cc
@@ -630,6 +630,8 @@ pthread::cancel ()
       threadlist_t *tl_entry = cygheap->find_tls (cygtls);
       if (!cygtls->inside_kernel (&context))
 	{
+	  if ((context._CX_stackPtr & 8) == 0)
+	    context._CX_stackPtr -= 8;
 	  context._CX_instPtr = (ULONG_PTR) pthread::static_cancel_self;
 	  SetThreadContext (win32_obj_id, &context);
 	}

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>