X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6E6833861861
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1707991195;
	bh=vBKlI2IS7aG4BrLv6PDCCFgHzXdQUVzL4jvbpMWzm80=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=kIhCxreEA0LK1aDXavKyvukb3bN4nhL/7bPEPpt0dQVOX+PMBgBhNkJLAS49o+WDi
	 kx/TxtUS4d/KV+F1qyQVX1Wg1ZYogZq1tJ03zaTDUHLj9/sKyLSHWNdeBPICZ4kw0E
	 SqMibmagTD+BXlHg/SlXajw/oHtSXw9nff6+GTyA=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D31D3386183D
Date: Thu, 15 Feb 2024 10:59:28 +0100
To: Kevin Ushey <kevinushey AT gmail DOT com>
Subject: Re: Cygwin installer hangs when running post-install scripts
Message-ID: <Zc3ggLcaKHjtDjLD@calimero.vinschen.de>
Mail-Followup-To: Kevin Ushey <kevinushey AT gmail DOT com>, cygwin AT cygwin DOT com
References: <CAJXgQP0ZpcQXON_oKbgE=S8Y-M=9+b00cZ6s4Het01TCTp3ajA AT mail DOT gmail DOT com>
 <Zcs_54Sakt48iAUd AT calimero DOT vinschen DOT de>
 <ZcuYBL3D2rSjlhNu AT calimero DOT vinschen DOT de>
 <CAJXgQP3YzDiomDUvOG30JfSAbe5d3EgLDRvbsT8yN73aAswPLA AT mail DOT gmail DOT com>
 <Zcu761ZXudxviCKv AT calimero DOT vinschen DOT de>
 <CAJXgQP3L5Wq9ZmVUJ2K+wt04Nh15QTjt2e9SF07TYwS8Bg15rg AT mail DOT gmail DOT com>
 <ZcyNTIuY728RhUTg AT calimero DOT vinschen DOT de>
 <ZczAeBlaEk7Syuwd AT calimero DOT vinschen DOT de>
 <CAJXgQP2ueV4tuTvW5Axm_R6PFX_yHKUuYRwvTy98aPsZCdj8uQ AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJXgQP2ueV4tuTvW5Axm_R6PFX_yHKUuYRwvTy98aPsZCdj8uQ@mail.gmail.com>
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: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>, cygwin AT cygwin DOT com
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 Feb 14 13:49, Kevin Ushey via Cygwin wrote:
> Thanks for your patience. Here's what I've got for the assembly around
> get_dir. I added a bit of debug logging just so I could get the
> function addresses:

First of all, thanks for taking the time to debug this further!

> C:\cygwin\bin>cygpath
> get_dir = 0x7FFB85E251B0
> rcall = 0x7FFB85E251CB
> 
> And here's what WinDbg reports:
> 
>     ntdll!EXP+#RtlGetCurrentDirectory_U:
> 00007ffb`85e251b0 488bc4     mov     rax, rsp
> 00007ffb`85e251b3 48895820   mov     qword ptr [rax+20h], rbx
> 00007ffb`85e251b7 55         push    rbp
> 00007ffb`85e251b8 5d         pop     rbp
> 00007ffb`85e251b9 e9721e2b00 jmp     ntdll!#RtlGetCurrentDirectory_U
> (7ffb860d7030)
> 00007ffb`85e251be cc         int     3
> 00007ffb`85e251bf cc         int     3
>     ntdll!EXP+#RtlGetCurrentPeb:
> 00007ffb`85e251c0 488bc4     mov     rax, rsp
> 00007ffb`85e251c3 48895820   mov     qword ptr [rax+20h], rbx
> 00007ffb`85e251c7 55         push    rbp
> 00007ffb`85e251c8 5d         pop     rbp
> 00007ffb`85e251c9 e9e2e82400 jmp     ntdll!#RtlGetCurrentPeb (7ffb86073ab0)
> 00007ffb`85e251ce cc         int     3
> 00007ffb`85e251cf cc         int     3
> 
> I'm not sure what the "EXP+#" prefix here means, but it appears to
> just be a stub that calls into the real implementation now?

Yes, that seems to be the case, same EXP+#for RtlGetCurrentPeb.

> So, if I'm understanding correctly:
> 
> 1. Cygwin was expecting to find a 'call' instruction somewhere
> following (the procedure address for) RtlGetCurrentDirectory_U;
> 2. The expected 'call' instruction no longer exists; however, by
> chance, there is a 'jmp' later on that includes '0xe8' in the bytes of
> the address to be jumped to;

That's it.  Chances are high that the above ntdll code was always more
or less the same and find_fast_cwd_pointer() failed all the time.  Only,
it never found the "e8" and so nothing bad happened.

So, as long as we don't know how to fix this correctly, my patch
4e77fa9b8bf4 ("Cygwin: find_fast_cwd: don't run assembler checking code
on ARM64") seems the right thing to do.

What annoys me is that I don't have access to ARM64 myself.  I tried
to install Windows for ARM64 on a QEmu emulator, but the VM always
failed to boot into Windows, it just sat there and used up CPU.
I even contemplated installing an Azure ARM64 VM, but I always shy
away from cloud services at the point they ask you for your size of
shoe and your social security number.

Anyway...

> For reference, here's what I see on my Intel Windows 11 machine, where
> all works as normal (showing up to the "call" instruction)

I wonder if you would be willing to grant us a view into the
ntdll!#RtlGetCurrentDirectory_U function jumped to from
ntdll!EXP+#RtlGetCurrentDirectory_U.  Per your above assembler output,
that would be at 7ffb860d7030.  Would you mind to post the WinDBG
assembler output of that function as well, even if just for curiosity?


Thanks,
Corinna

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