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