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