DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 5BNHgAsp3758057
Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 5BNHgAsp3758057
Authentication-Results: delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=T9ntjVe/
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 370284BA2E23
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1766511729;
	bh=2FtMiDGY+0fHpQUVk9zxczdZis+aLN0jYqvnIi97aTo=;
	h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	 From;
	b=T9ntjVe/bTeXYwehO5r1YvNS5NeamG02KlPEbFJZMabzHFCIRByTxy582VR/o8knr
	 2wT3tgD8BjBEqxBuGwH/HOdiZ7epntpUEtEx7sVavWzHmlbfMAWwScb43nwwbWkU8x
	 TNbYyT98GXjWxFLJehkJj3tAvqXqrrGul9S3aHYI=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9827B4BA2E05
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9827B4BA2E05
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1766511673; cv=none;
 b=q5fRB2SRtSaLu29hyRRln2VBM+p+73ubjN48QVKR1duV+/S044G1oyY4uElcn3I3Y0aU8pqvrUZtgeGM7feR/oOujCrbd28UG2oDHqKB6N9S7wH21Q3eO6gYk1qxNpAXh7T8MadG6R5gw8uMqNRmWtek4llB0diQ6T1QqZdUvSU=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1766511673; c=relaxed/simple;
 bh=nnemRvTcco9iRFE39Q0TntF/ZZ0bp/hX161SFGKqDi8=;
 h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature;
 b=GLVVFjvpVBSFsTiUy/Z21T1AW3NLt+BdEE3+AkqfRHDbyBxJsJGKUlv8g5eW0/R4IdxCcg24aoLJ+q6ZlsJp2tWHi1a1z3egNnqtoBEfz38fZv+8vsEHyAcVPaeAHZhLJXLHqmrD/MQNC8QDg2ZNITMChhnTMeuolDlJuqUPwMQ=
ARC-Authentication-Results: i=1; server2.sourceware.org
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9827B4BA2E05
Date: Wed, 24 Dec 2025 02:41:09 +0900
To: cygwin AT cygwin DOT com
Subject: Re: Recent testsuite/winsup.api/pthread/cancel2 failure
Message-Id: <20251224024109.3fad5d4d8aced800ad916caf@nifty.ne.jp>
In-Reply-To: <20251223190713.e2efc476782898d55f00b64f@nifty.ne.jp>
References: <20251214162637 DOT 1ee05b084788ba073fe94670 AT nifty DOT ne DOT jp>
 <20251214163936 DOT 6841fc62145d8f54cfa31fe7 AT nifty DOT ne DOT jp>
 <9d058204-fb3f-43b4-9e32-6adc7af12ff4 AT dronecode DOT org DOT uk>
 <20251217193737 DOT 3d3d686ebe3865c183315dc5 AT nifty DOT ne DOT jp>
 <20251222230450 DOT a2e308861cebfab9cdb5dcc1 AT nifty DOT ne DOT jp>
 <20251222233746 DOT d45ae16e4e06de5af7b27f26 AT nifty DOT ne DOT jp>
 <aUln7b98tXZ6juG8 AT calimero DOT vinschen DOT de>
 <20251223190713 DOT e2efc476782898d55f00b64f AT nifty DOT ne DOT jp>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
Mime-Version: 1.0
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Takashi Yano via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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>

On Tue, 23 Dec 2025 19:07:13 +0900
Takashi Yano wrote:
> On Mon, 22 Dec 2025 16:46:53 +0100
> Corinna Vinschen wrote:
> > On Dec 22 23:37, Takashi Yano via Cygwin wrote:
> > > 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;
> > 
> > Does that really help?  Checking for 8 byte alignment is usually done
> > with (X & 7) != 0, because this won't catch 16 byte aligned stacks.
> 
> This code does not aim for 8 byte alignment, but 16n + 8. I assume
> context._CX_stackPtr & 7 is always 0. I wonder if this assumption
> is true. What if user code pushes 16 bit register such as AX?
> It might be necessary to mask least 3 bits in advance.
> 
> diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
> index 86a00e76e..628aef16f 100644
> --- a/winsup/cygwin/thread.cc
> +++ b/winsup/cygwin/thread.cc
> @@ -630,6 +630,9 @@ pthread::cancel ()
>        threadlist_t *tl_entry = cygheap->find_tls (cygtls);
>        if (!cygtls->inside_kernel (&context))
>  	{
> +	  context._CX_stackPtr &= 0xfffffffffffffff8UL;
> +	  if ((context._CX_stackPtr & 8) == 0)
> +	    context._CX_stackPtr -= 8;
>  	  context._CX_instPtr = (ULONG_PTR) pthread::static_cancel_self;
>  	  SetThreadContext (win32_obj_id, &context);
>  	}
> 
> > But afaic the stack is always 8 byte aligned anyway.  However, there are
> > some scenarios where 16 byte alignment is required, as for context
> > itself when calling RtlCaptureContext.  Maybe that's the problem here?
> 
> I think so. x86_64 ABI in Windows requires 16 byte alignment.
> https://learn.microsoft.com/en-us/cpp/build/stack-usage?view=msvc-170
> says:
>     The stack will always be maintained 16-byte aligned, except
>     within the prolog (for example, after the return address is pushed), 
> 
> Therefore, stack alignment here must be 16n +  8 byte alignment.
> Because 'call' instruction pushes the RIP (8 byte) into stack,
> while the code
> context._CX_instPtr = (ULONG_PTR) pthread::static_cancel_self;
> does not do that.
> 
> > But the context Stackptr is the stackpointer of the current function the
> > target thread is running in.  The instruction pointer is set to
> > pthread::static_cancel_self(), which doesn't get any arguments and doesn't
> > use any content from the stack.
> 
> Yeah, that was my question.
> 
> > It might be a good idea to make sure the stack is always 16 byte
> > aligned, but I don't see why pthread::static_cancel_self() ->
> > pthread::cancel_self() -> pthread::exit() would require other than 8
> > byte alignment.
> 
> pthread::exit() calls _cygtls::remove(), and it calls CloseHandle(),
> It appears that, from a certain point, CloseHandle() stopped working
> unless it was 16n + 8 byte aligned.

I confirmed that SbSelectProdedure() does not use 'movaps' instruction
in Windows 10 22H2, while it uses 'movaps' in Win 11 25H2.

On Tue, 16 Dec 2025 13:11:15 +0000
Jon Turney wrote:
> 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...

I guess the same is true between Windows Server 2022 and Windows Server 2025.

> On 14/12/2025 07:39, Takashi Yano via Cygwin wrote:
> >> 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.

Perhaps, NtClose() does not use SbSelectProcedure(), then it works
on 8 byte alignment by chance.

-- 
Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>

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