Re: Recent testsuite/winsup.api/pthread/cancel2 failure

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 <[email protected]> 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?

-- 
Takashi Yano <[email protected]>

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