X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1F8BB3860750
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1707947423;
	bh=eGTiT3L+2Mgg9PsHzI5jx8nSXM/qI9kNNXyZ1nepZ0Q=;
	h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	 From;
	b=ThVZUfQCFIRn5Heh5BN1GBMmnZ9hX3o/1C9Qm9PLPidc+EmZBg3wFJUfQ981xkVfJ
	 gCEiG03jucd24LQ8aglIFQgTDUAPNwKxu1zaZMWYe+fNtCu9i/Z/wUtfDNW+OSNlbi
	 u5ZG8DfnvzVhbS7Qu3DPX3+9kFFXc+DqoeNIzmRg=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E0C9A3860750
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E0C9A3860750
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707947401; cv=none;
 b=CnS5/dYXvbxWuKPwa14m+vwH4PMv2d2Q0KqdUspxHImRlHyAK90aIbEwuvA2UnfpAuZNaRd/6JSTaaxoI9d0pd0Qev4XB2r7YpvYMRDVlXspb3vikRmr61VRO8zlLOMHaBp5maBJHLKYl3bQu+yK9uM3hDqG++N1w5aiDb3P8Gg=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1707947401; c=relaxed/simple;
 bh=heq0Aucz8+WBx1WL2SHxWziNJDI20s7kNZlAQK+uQ18=;
 h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;
 b=v9gLmCQYJzx/RGvxn8211yFA2IQh6QV76HeHQHWVepeFHyk6WLrY36KQOze64YHXfiZnju4zJuyaesVG1CfIDIA7l+yrUWMJrarDFszGG6pWncKGRH7MtQ/MFBsKFatUKCRS6LZ/U4BoUgy15blbLSpveygjvwdkVsv+7bTOYj0=
ARC-Authentication-Results: i=1; server2.sourceware.org
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1707947399; x=1708552199;
 h=content-transfer-encoding:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=TUc4vA5kXwZKLPeTAgnw6k39Xf0idstwg209a+NOuM4=;
 b=Yt/+jkmdUuA/2iKmO7zQ8YCMi3VHyJNH75BbmupZIrJPVeOzZDDEr0MikW5XylgVmm
 majjtgoHwHMOi/+uKkmSepw4qXZEMLoo/xElP66fsDEa8GqpSeqBlD7x1ltBbrU2Knlu
 MX7meK1KfPv5cvHsA6l6P+uW251TGPwuUpXUMlpV6THjAIlperjpk1crqstIbSMssUHT
 /JmaiyushRwiMeHny6wpr4chWfZWpds+ey75J6yNJwBtnZI6Ix0+A4sS7gJ/snzAbYS7
 ELGJbs0BvM2vaHddoYZ1RnGg/LyYfrfq/CIs6P1alZ+m29Kq3Q4BSG0cM3aulnmACGxE
 v10A==
X-Gm-Message-State: AOJu0YxQOP7siNe0Obw8VrrhZNsdriaUE/xzmJ0Cm4Jdj7Pj5ezzmkcW
 ILHjbZrq2waCQ9vIcUd+fjPtJ7fBotrjL0h++nJFfCXPibD5LsihesAGVvZu6LEQBprKZ/HSpEr
 RqxWltL8CNCetRvHRQ+BTzz31muViLRNL
X-Google-Smtp-Source: AGHT+IEezTTDdb3ojIqun78uj0fsjrJg+FPaPfurfPuACdT/LVUbIPKUpMHnmMtzDCAdbI1PAAVFz8v/bjC1zSEEL5g=
X-Received: by 2002:a5b:ec2:0:b0:dc7:48f8:ce2e with SMTP id
 a2-20020a5b0ec2000000b00dc748f8ce2emr3267591ybs.37.1707947398576; Wed, 14 Feb
 2024 13:49:58 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <ZczAeBlaEk7Syuwd@calimero.vinschen.de>
Date: Wed, 14 Feb 2024 13:49:21 -0800
Message-ID: <CAJXgQP2ueV4tuTvW5Axm_R6PFX_yHKUuYRwvTy98aPsZCdj8uQ@mail.gmail.com>
Subject: Re: Cygwin installer hangs when running post-install scripts
To: cygwin AT cygwin DOT com, Kevin Ushey <kevinushey AT gmail DOT com>
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
 SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE,
 WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
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: Kevin Ushey via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Kevin Ushey <kevinushey AT gmail DOT com>
Content-Type: text/plain; charset="utf-8"
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 41ELoOug010763

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:

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?

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;
3. In computing 'rcall', the call to memchr ends up finding that bit,
and everything goes haywire from there.

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

    ntdll!RtlGetCurrentDirectory_U:
00007ffe`4cacb640 488bc4           mov     rax, rsp
00007ffe`4cacb643 48895808         mov     qword ptr [rax+8], rbx
00007ffe`4cacb647 48896810         mov     qword ptr [rax+10h], rbp
00007ffe`4cacb64b 48897018         mov     qword ptr [rax+18h], rsi
00007ffe`4cacb64f 48897820         mov     qword ptr [rax+20h], rdi
00007ffe`4cacb653 4154             push    r12
00007ffe`4cacb655 4156             push    r14
00007ffe`4cacb657 4157             push    r15
00007ffe`4cacb659 4883ec20         sub     rsp, 20h
00007ffe`4cacb65d 448bf9           mov     r15d, ecx
00007ffe`4cacb660 4c8bf2           mov     r14, rdx
00007ffe`4cacb663 b101             mov     cl, 1
00007ffe`4cacb665 e8be000000       call
ntdll!RtlpReferenceCurrentDirectory (7ffe4cacb728)

Best,
Kevin





On Wed, Feb 14, 2024 at 5:30 AM Corinna Vinschen
<corinna-cygwin AT cygwin DOT com> wrote:
>
> On Feb 14 10:52, Corinna Vinschen via Cygwin wrote:
> > On Feb 13 15:48, Kevin Ushey via Cygwin wrote:
> > > Here's a bit more information from a debug build of cygwin; here I'm
> > > just trying to launch cygpath.exe:
> > >
> > > (gdb) f 1
> > > #1  0x00007ffa0123ba1f in find_fast_cwd_pointer () at
> > > ../../../../winsup/cygwin/path.cc:4526
> > > 4526      const uint8_t *lock = (const uint8_t *)
> > >
> > > (gdb) bt
> > > #0  memmem (haystack=<optimized out>, hs_len=<optimized out>,
> > > needle=0x7ffa0142e531 <_C_collate_locale+59857>, ne_len=4) at
> > > ../../../newlib/libc/string/memmem.c:161
> > > #1  0x00007ffa0123ba1f in find_fast_cwd_pointer () at
> > > ../../../../winsup/cygwin/path.cc:4526
> > > [...]
> >
> > Ok, so we know now which memmem call fails, so the next question is,
> > why?  The haystack address is unfortunately still optimized out in
> > memmem, so it looks like the newlib subdir is still optimized.
> > But it's pretty certainly a wrong haystack address.  This address has
> > been fetched from
> >
> >   const uint8_t *rcall = (const uint8_t *) memchr (get_dir, 0xe8, 80);
> >   ...
> >   const uint8_t *use_cwd = rcall + 5 + peek32 (rcall + 1);
> >
> > Chances are high, that the call instruction found by rcall is bogus.
>
> Can you run this in GDB?  I'd love to see the assembler code starting at
> address `get_dir'...
>
>
> 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