Re: Cygwin installer hangs when running post-install scripts
On Feb 20 10:33, Kevin Ushey via Cygwin wrote: > Hi Corinna, > > I just updated > https://gist.github.com/kevinushey/cdbd15cdf22e5cdcd094b0ad80347dce > with that output (windbg-output-2.txt); let me know if that gives you > what you need. Thank you! Not sure I'll follow up on this, ARM64 assembler still puzzles me. However, this way I can at least take a look. Thanks again, 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
Re: Cygwin installer hangs when running post-install scripts
Hi Corinna, I just updated https://gist.github.com/kevinushey/cdbd15cdf22e5cdcd094b0ad80347dce with that output (windbg-output-2.txt); let me know if that gives you what you need. As an aside, a new version of the Windows Insider edition was just released, and the memory addresses for the stubs in ntdll.dll have changed such that the original issue no longer occurs (ie, 0xe8 no longer happens to be part of the jumped-to address in the following stub), but I presume that is just luck and not an intentional change. Best, Kevin On Mon, Feb 19, 2024 at 6:36 AM Corinna Vinschen wrote: > > Hi Kevin, > > On Feb 15 20:13, Corinna Vinschen via Cygwin wrote: > > On Feb 15 09:46, Kevin Ushey via Cygwin wrote: > > > https://gist.github.com/kevinushey/cdbd15cdf22e5cdcd094b0ad80347dce. > > [...] > > 0001`802b7054 db030094 bl ntdll!#RtlpReferenceCurrentDirectory > > (1802b7fc0) > > I'm not familiar with ARM assembler, but a quick search showed that the > `bl' opcode is basically a subroutine call. > > So ntdll!#RtlpReferenceCurrentDirectory is not the address of the struct > pointer, as I surmised, but the address of the function (probably) > fetching the address of the struct pointer. > > Would you mind to send the assembler output for this function as well? > > > 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
Re: Cygwin installer hangs when running post-install scripts
Hi Kevin, On Feb 15 20:13, Corinna Vinschen via Cygwin wrote: > On Feb 15 09:46, Kevin Ushey via Cygwin wrote: > > https://gist.github.com/kevinushey/cdbd15cdf22e5cdcd094b0ad80347dce. > [...] > 0001`802b7054 db030094 bl ntdll!#RtlpReferenceCurrentDirectory > (1802b7fc0) I'm not familiar with ARM assembler, but a quick search showed that the `bl' opcode is basically a subroutine call. So ntdll!#RtlpReferenceCurrentDirectory is not the address of the struct pointer, as I surmised, but the address of the function (probably) fetching the address of the struct pointer. Would you mind to send the assembler output for this function as well? 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
Re: Cygwin installer hangs when running post-install scripts
On Feb 15 09:46, Kevin Ushey via Cygwin wrote: > Thanks -- I've put the associated WinDbg output up at > https://gist.github.com/kevinushey/cdbd15cdf22e5cdcd094b0ad80347dce. > (Sharing it externally just because it's relatively large.) Thank you! > The important thing to note is that #RtlGetCurrentDirectory_U appears > to be valid ARM assembly, but not x86_64 assembly. My hypothesis here > is that the stub is used to allow emulated x86_64 processes to call > back into native ARM code... which would further confirm that > disabling the find_fast_cwd_pointer checks for ARM is the correct > choice. I guess so, but I'm quite puzzled how the emulator is supposed to know that it just left the x86_64 assembler code. Magic!!! Checking the ARM code, it might even be possible to come up with a real solution, given this line in the first few bytes of ntdll!#RtlGetCurrentDirectory_U: 0001`802b7054 db030094 bl ntdll!#RtlpReferenceCurrentDirectory (1802b7fc0) This seems to fetch the address of the pointer we're interested in. It's unlikely (but not impossible) that the structure differs from the same struct as on x86_64. We may have a chance there, but I would feel better if I could debug my code by myself. 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
Re: Cygwin installer hangs when running post-install scripts
Thanks -- I've put the associated WinDbg output up at
https://gist.github.com/kevinushey/cdbd15cdf22e5cdcd094b0ad80347dce.
(Sharing it externally just because it's relatively large.)
The important thing to note is that #RtlGetCurrentDirectory_U appears
to be valid ARM assembly, but not x86_64 assembly. My hypothesis here
is that the stub is used to allow emulated x86_64 processes to call
back into native ARM code... which would further confirm that
disabling the find_fast_cwd_pointer checks for ARM is the correct
choice.
Best,
Kevin
On Thu, Feb 15, 2024 at 1:59 AM Corinna Vinschen
wrote:
>
> 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:
> > 7ffb`85e251b0 488bc4 mov rax, rsp
> > 7ffb`85e251b3 48895820 mov qword ptr [rax+20h], rbx
> > 7ffb`85e251b7 55 pushrbp
> > 7ffb`85e251b8 5d pop rbp
> > 7ffb`85e251b9 e9721e2b00 jmp ntdll!#RtlGetCurrentDirectory_U
> > (7ffb860d7030)
> > 7ffb`85e251be cc int 3
> > 7ffb`85e251bf cc int 3
> > ntdll!EXP+#RtlGetCurrentPeb:
> > 7ffb`85e251c0 488bc4 mov rax, rsp
> > 7ffb`85e251c3 48895820 mov qword ptr [rax+20h], rbx
> > 7ffb`85e251c7 55 pushrbp
> > 7ffb`85e251c8 5d pop rbp
> > 7ffb`85e251c9 e9e2e82400 jmp ntdll!#RtlGetCurrentPeb (7ffb86073ab0)
> > 7ffb`85e251ce cc int 3
> > 7ffb`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
Re: Cygwin installer hangs when running post-install scripts
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:
> 7ffb`85e251b0 488bc4 mov rax, rsp
> 7ffb`85e251b3 48895820 mov qword ptr [rax+20h], rbx
> 7ffb`85e251b7 55 pushrbp
> 7ffb`85e251b8 5d pop rbp
> 7ffb`85e251b9 e9721e2b00 jmp ntdll!#RtlGetCurrentDirectory_U
> (7ffb860d7030)
> 7ffb`85e251be cc int 3
> 7ffb`85e251bf cc int 3
> ntdll!EXP+#RtlGetCurrentPeb:
> 7ffb`85e251c0 488bc4 mov rax, rsp
> 7ffb`85e251c3 48895820 mov qword ptr [rax+20h], rbx
> 7ffb`85e251c7 55 pushrbp
> 7ffb`85e251c8 5d pop rbp
> 7ffb`85e251c9 e9e2e82400 jmp ntdll!#RtlGetCurrentPeb (7ffb86073ab0)
> 7ffb`85e251ce cc int 3
> 7ffb`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
Re: Cygwin installer hangs when running post-install scripts
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: 7ffb`85e251b0 488bc4 mov rax, rsp 7ffb`85e251b3 48895820 mov qword ptr [rax+20h], rbx 7ffb`85e251b7 55 pushrbp 7ffb`85e251b8 5d pop rbp 7ffb`85e251b9 e9721e2b00 jmp ntdll!#RtlGetCurrentDirectory_U (7ffb860d7030) 7ffb`85e251be cc int 3 7ffb`85e251bf cc int 3 ntdll!EXP+#RtlGetCurrentPeb: 7ffb`85e251c0 488bc4 mov rax, rsp 7ffb`85e251c3 48895820 mov qword ptr [rax+20h], rbx 7ffb`85e251c7 55 pushrbp 7ffb`85e251c8 5d pop rbp 7ffb`85e251c9 e9e2e82400 jmp ntdll!#RtlGetCurrentPeb (7ffb86073ab0) 7ffb`85e251ce cc int 3 7ffb`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: 7ffe`4cacb640 488bc4 mov rax, rsp 7ffe`4cacb643 48895808 mov qword ptr [rax+8], rbx 7ffe`4cacb647 48896810 mov qword ptr [rax+10h], rbp 7ffe`4cacb64b 48897018 mov qword ptr [rax+18h], rsi 7ffe`4cacb64f 48897820 mov qword ptr [rax+20h], rdi 7ffe`4cacb653 4154 pushr12 7ffe`4cacb655 4156 pushr14 7ffe`4cacb657 4157 pushr15 7ffe`4cacb659 4883ec20 sub rsp, 20h 7ffe`4cacb65d 448bf9 mov r15d, ecx 7ffe`4cacb660 4c8bf2 mov r14, rdx 7ffe`4cacb663 b101 mov cl, 1 7ffe`4cacb665 e8be00 call ntdll!RtlpReferenceCurrentDirectory (7ffe4cacb728) Best, Kevin On Wed, Feb 14, 2024 at 5:30 AM Corinna Vinschen 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 0x7ffa0123ba1f in find_fast_cwd_pointer () at > > > ../../../../winsup/cygwin/path.cc:4526 > > > 4526 const uint8_t *lock = (const uint8_t *) > > > > > > (gdb) bt > > > #0 memmem (haystack=, hs_len=, > > > needle=0x7ffa0142e531 <_C_collate_locale+59857>, ne_len=4) at > > > ../../../newlib/libc/string/memmem.c:161 > > > #1 0x7ffa0123ba1f 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
Re: Cygwin installer hangs when running post-install scripts
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 0x7ffa0123ba1f in find_fast_cwd_pointer () at > > ../../../../winsup/cygwin/path.cc:4526 > > 4526 const uint8_t *lock = (const uint8_t *) > > > > (gdb) bt > > #0 memmem (haystack=, hs_len=, > > needle=0x7ffa0142e531 <_C_collate_locale+59857>, ne_len=4) at > > ../../../newlib/libc/string/memmem.c:161 > > #1 0x7ffa0123ba1f 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
Re: Cygwin installer hangs when running post-install scripts
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 0x7ffa0123ba1f in find_fast_cwd_pointer () at
> ../../../../winsup/cygwin/path.cc:4526
> 4526 const uint8_t *lock = (const uint8_t *)
>
> (gdb) bt
> #0 memmem (haystack=, hs_len=,
> needle=0x7ffa0142e531 <_C_collate_locale+59857>, ne_len=4) at
> ../../../newlib/libc/string/memmem.c:161
> #1 0x7ffa0123ba1f 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.
> Diving in further is a bit beyond my level of experience with Windows
> internals.
It would be great if you could run this under GDB and check the
assembler code inside the ntdll.dll this code is scanning. You
don't really need knowledge of Windows internals, it's basically
just really dumb scanning of assembler code for certain instructions,
and the expected assembler code is x86_64.
> I wonder if it'd be
> worth having cygwin respect an environment variable like
> CYGWIN_USE_FAST_CWD_POINTER, so that users could opt out of this
> particular optimization if it happens to break on new versions of
> Windows, as I have seemingly encountered.
My latest patch already does it, no env var required.
> As an aside, I had to make a couple of small patches to side-step gcc
> warnings (converted to errors) during build; I tried building with "-g
> -Og" flags.
I'm usually building with -ggdb only, or with -ggdb -O2.
I just added -Og, and checked the below code. I'm not so sure about the
usefulness of -Og, given that all three warnings are false positives...
> $ git diff
> diff --git a/winsup/cygwin/fhandler/fifo.cc b/winsup/cygwin/fhandler/fifo.cc
> index efea508ae..f288e874a 100644
> --- a/winsup/cygwin/fhandler/fifo.cc
> +++ b/winsup/cygwin/fhandler/fifo.cc
> @@ -669,7 +669,7 @@ fhandler_fifo::create_shmem (bool only_open)
> {
>HANDLE sect;
>OBJECT_ATTRIBUTES attr;
> - NTSTATUS status;
> + NTSTATUS status = 0;
>LARGE_INTEGER size = { .QuadPart = sizeof (fifo_shmem_t) };
>SIZE_T viewsize = sizeof (fifo_shmem_t);
>PVOID addr = NULL;
My gcc (11.3.0) did not show this, even with -Og. However, the status
var always gets set, see lines 685 - 695.
> diff --git a/winsup/cygwin/tty.cc b/winsup/cygwin/tty.cc
> index bf7c6010f..2cd4ae6ed 100644
> --- a/winsup/cygwin/tty.cc
> +++ b/winsup/cygwin/tty.cc
> @@ -323,7 +323,7 @@ tty::wait_fwd ()
> thread when the last data is transfered. */
>const ULONGLONG sleep_in_nat_pipe = 16;
>const ULONGLONG time_to_wait = sleep_in_nat_pipe * 2 + 1/* margine */;
> - ULONGLONG elapsed;
> + ULONGLONG elapsed = 0;
>while (fwd_not_empty
> || (elapsed = GetTickCount64 () - fwd_last_time) < time_to_wait)
> {
fwd_not_empty is false for a start, so GetTickCount64() is called at
least once.
> diff --git a/winsup/utils/kill.cc b/winsup/utils/kill.cc
> index fb45e4c9d..bcabcd47c 100644
> --- a/winsup/utils/kill.cc
> +++ b/winsup/utils/kill.cc
> @@ -73,7 +73,7 @@ print_version ()
> static const char *
> strsigno (int signo)
> {
> - static char sigbuf[8];
> + static char sigbuf[32];
>
>if (signo > 0 && signo < SIGRTMIN)
> return sys_sigabbrev[signo];
We're calling snprintf here for a reason, and we know that the
number has never more than 2 digits. Oh well.
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
Re: Cygwin installer hangs when running post-install scripts
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 0x7ffa0123ba1f in find_fast_cwd_pointer () at
../../../../winsup/cygwin/path.cc:4526
4526 const uint8_t *lock = (const uint8_t *)
(gdb) bt
#0 memmem (haystack=, hs_len=,
needle=0x7ffa0142e531 <_C_collate_locale+59857>, ne_len=4) at
../../../newlib/libc/string/memmem.c:161
#1 0x7ffa0123ba1f in find_fast_cwd_pointer () at
../../../../winsup/cygwin/path.cc:4526
#2 0x7ffa0123bb7d in find_fast_cwd () at
../../../../winsup/cygwin/path.cc:4614
#3 0x7ffa0123fd39 in cwdstuff::override_win32_cwd
(this=this@entry=0x84840, init=init@entry=true,
old_dismount_count=old_dismount_count@entry=0) at
../../../../winsup/cygwin/path.cc:4649
#4 0x7ffa0124035c in cwdstuff::set (this=0x84840,
nat_cwd=nat_cwd@entry=0x0, posix_cwd=posix_cwd@entry=0x0) at
../../../../winsup/cygwin/path.cc:4999
#5 0x7ffa012404fb in cwdstuff::init (this=) at
../../../../winsup/cygwin/path.cc:4739
#6 0x7ffa011f78bd in dll_crt0_1 () at
../../../../winsup/cygwin/dcrt0.cc:839
#7 0x7ffa011f5c5f in _cygtls::call2 (this=0x7ce00,
func=0x7ffa011f782b , arg=0x0,
buf=buf@entry=0x7cdc0) at ../../../../winsup/cygwin/cygtls.cc:41
#8 0x7ffa011f5ccc in _cygtls::call (func=,
arg=) at ../../../../winsup/cygwin/cygtls.cc:28
#9 0x7ffa011f72f1 in _dll_crt0 () at
../../../../winsup/cygwin/dcrt0.cc:1052
#10 0x in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) info locals
ntdll =
get_dir =
ent_crit = 0x7ffa885a4b70 "H\213\304H\211X U]\351\342\214\030"
rcall = 0x7ffa885a51cb
use_cwd = 0x7ffa552651f4
movrbx =
lock =
testrbx =
which would suggest this bit of code (using the GitHub mirror just for
ease-of-use in linking)
https://github.com/cygwin/cygwin/blob/4e77fa9b8bf4818ff90c013f7e7b2b0ac0b968c5/winsup/cygwin/path.cc#L4519-L4528
Diving in further is a bit beyond my level of experience with Windows
internals. Anything else I can try and provide? I wonder if it'd be
worth having cygwin respect an environment variable like
CYGWIN_USE_FAST_CWD_POINTER, so that users could opt out of this
particular optimization if it happens to break on new versions of
Windows, as I have seemingly encountered.
As an aside, I had to make a couple of small patches to side-step gcc
warnings (converted to errors) during build; I tried building with "-g
-Og" flags.
$ git diff
diff --git a/winsup/cygwin/fhandler/fifo.cc b/winsup/cygwin/fhandler/fifo.cc
index efea508ae..f288e874a 100644
--- a/winsup/cygwin/fhandler/fifo.cc
+++ b/winsup/cygwin/fhandler/fifo.cc
@@ -669,7 +669,7 @@ fhandler_fifo::create_shmem (bool only_open)
{
HANDLE sect;
OBJECT_ATTRIBUTES attr;
- NTSTATUS status;
+ NTSTATUS status = 0;
LARGE_INTEGER size = { .QuadPart = sizeof (fifo_shmem_t) };
SIZE_T viewsize = sizeof (fifo_shmem_t);
PVOID addr = NULL;
diff --git a/winsup/cygwin/tty.cc b/winsup/cygwin/tty.cc
index bf7c6010f..2cd4ae6ed 100644
--- a/winsup/cygwin/tty.cc
+++ b/winsup/cygwin/tty.cc
@@ -323,7 +323,7 @@ tty::wait_fwd ()
thread when the last data is transfered. */
const ULONGLONG sleep_in_nat_pipe = 16;
const ULONGLONG time_to_wait = sleep_in_nat_pipe * 2 + 1/* margine */;
- ULONGLONG elapsed;
+ ULONGLONG elapsed = 0;
while (fwd_not_empty
|| (elapsed = GetTickCount64 () - fwd_last_time) < time_to_wait)
{
diff --git a/winsup/utils/kill.cc b/winsup/utils/kill.cc
index fb45e4c9d..bcabcd47c 100644
--- a/winsup/utils/kill.cc
+++ b/winsup/utils/kill.cc
@@ -73,7 +73,7 @@ print_version ()
static const char *
strsigno (int signo)
{
- static char sigbuf[8];
+ static char sigbuf[32];
if (signo > 0 && signo < SIGRTMIN)
return sys_sigabbrev[signo];
Thanks,
Kevin
On Tue, Feb 13, 2024 at 10:58 AM Corinna Vinschen
wrote:
>
> On Feb 13 10:01, Kevin Ushey via Cygwin wrote:
> > On Tue, Feb 13, 2024 at 8:25 AM Corinna Vinschen wrote:
> > > On Feb 13 11:09, Corinna Vinschen via Cygwin wrote:
> > > > Other than that, the only thing you really could do at this point is to
> > > > check Cygwin's find_fast_cwd_pointer() function and go through this
> > > > function step by step, diving into the assembler code this function
> > > > inspects trying to find out which of the memmem calls fails and how to
> > > > fix it. And send a patch eventually.
> > > > [...]
> > > > One thing we can do is to skip the find_fast_cwd_pointer() code entirely
> > > > when running on AArch64, but it's a bit annoying, given this wasn't
> > > > necessary in previous AArch64 builds.
> > >
> > > I've just pushed a (temporary?) patch to do just that. This will be
> > > in the test build cygwin-3.6.0-0.37.g4e77fa9b8bf4 which will be
> > > installable via Cygwin's installer in an hour or two.
> >
> > Thank you for taking a look so quickly -- I can confirm your patch
> > fixes things for me; the installer now runs to completion and the
> > Cygwin64 Terminal +
Re: Cygwin installer hangs when running post-install scripts
On Feb 13 10:01, Kevin Ushey via Cygwin wrote: > On Tue, Feb 13, 2024 at 8:25 AM Corinna Vinschen wrote: > > On Feb 13 11:09, Corinna Vinschen via Cygwin wrote: > > > Other than that, the only thing you really could do at this point is to > > > check Cygwin's find_fast_cwd_pointer() function and go through this > > > function step by step, diving into the assembler code this function > > > inspects trying to find out which of the memmem calls fails and how to > > > fix it. And send a patch eventually. > > > [...] > > > One thing we can do is to skip the find_fast_cwd_pointer() code entirely > > > when running on AArch64, but it's a bit annoying, given this wasn't > > > necessary in previous AArch64 builds. > > > > I've just pushed a (temporary?) patch to do just that. This will be > > in the test build cygwin-3.6.0-0.37.g4e77fa9b8bf4 which will be > > installable via Cygwin's installer in an hour or two. > > Thank you for taking a look so quickly -- I can confirm your patch > fixes things for me; the installer now runs to completion and the > Cygwin64 Terminal + other installed tools all function correctly. Thanks for confirming. However, if you see *any* chance to check Cygwin's find_fast_cwd_pointer() pointer function and try to find out why it crashes, that would be very helpful. 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
Re: Cygwin installer hangs when running post-install scripts
Hi Corinna, Thank you for taking a look so quickly -- I can confirm your patch fixes things for me; the installer now runs to completion and the Cygwin64 Terminal + other installed tools all function correctly. Best, Kevin On Tue, Feb 13, 2024 at 8:25 AM Corinna Vinschen wrote: > > On Feb 13 11:09, Corinna Vinschen via Cygwin wrote: > > On Feb 12 14:38, Kevin Ushey via Cygwin wrote: > > > For reference, I first bumped into this when using Git Bash as bundled > > > with Git for Windows, but it sounds like the underlying issue may be > > > in Cygwin. See https://github.com/git-for-windows/git/issues/4808 for > > > more details. > > > > There is, however, the stacktrace from your above issue report on > > github, which makes more sense, and, incidentally, occurs in code > > following cygwin_split_path in the .text segment: > > > > (gdb) bt > > #0 0x0002101eeaf3 in memmem () from [...] > > #1 0x000210095d91 in cwdstuff::override_win32_cwd(bool, unsigned int) > > () > >from [...] > > #2 0x00021009642e in cwdstuff::set(path_conv*, char const*) () from > > [...] > > #3 0x000210047025 in dll_crt0_1(void*) () from [...] > > #4 [...] > > > > This points to something going wrong during startup, while trying > > to evaluate the global pointer to the hidden ntdll.dll struct we > > called, for want of an official expression, FAST_CWD structure. > > > > If we can rely on frame 1, a call to memmem crashes, that would > > mean the crash occurs in find_fast_cwd_pointer(). > > > > > Does any of this sound familiar? Is there anything else I can do to > > > get more information here; e.g. are there builds of Cygwin with debug > > > symbols published somewhere, or should I try producing my own debug > > > build? > > > > Well, you could have mentioned that this is on AArch64. Fortunately > > you did in the github case, but next time, please tell us here, too. > > > > I assume you can't run any Cygwin binary, even from outside the > > installer? > > > > Other than that, the only thing you really could do at this point is to > > check Cygwin's find_fast_cwd_pointer() function and go through this > > function step by step, diving into the assembler code this function > > inspects trying to find out which of the memmem calls fails and how to > > fix it. And send a patch eventually. > > > > However, there isn't much point there as long as this is an insider > > build. In the past, the code often changed and was uncritical in the > > next official release. > > > > One thing we can do is to skip the find_fast_cwd_pointer() code entirely > > when running on AArch64, but it's a bit annoying, given this wasn't > > necessary in previous AArch64 builds. > > I've just pushed a (temporary?) patch to do just that. This will be > in the test build cygwin-3.6.0-0.37.g4e77fa9b8bf4 which will be > installable via Cygwin's installer in an hour or two. > > Please try if this works for you and report back. You can use this > DLL as workaround for the time being then. > > > 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
Re: Cygwin installer hangs when running post-install scripts
On Feb 13 11:09, Corinna Vinschen via Cygwin wrote: > On Feb 12 14:38, Kevin Ushey via Cygwin wrote: > > For reference, I first bumped into this when using Git Bash as bundled > > with Git for Windows, but it sounds like the underlying issue may be > > in Cygwin. See https://github.com/git-for-windows/git/issues/4808 for > > more details. > > There is, however, the stacktrace from your above issue report on > github, which makes more sense, and, incidentally, occurs in code > following cygwin_split_path in the .text segment: > > (gdb) bt > #0 0x0002101eeaf3 in memmem () from [...] > #1 0x000210095d91 in cwdstuff::override_win32_cwd(bool, unsigned int) () >from [...] > #2 0x00021009642e in cwdstuff::set(path_conv*, char const*) () from [...] > #3 0x000210047025 in dll_crt0_1(void*) () from [...] > #4 [...] > > This points to something going wrong during startup, while trying > to evaluate the global pointer to the hidden ntdll.dll struct we > called, for want of an official expression, FAST_CWD structure. > > If we can rely on frame 1, a call to memmem crashes, that would > mean the crash occurs in find_fast_cwd_pointer(). > > > Does any of this sound familiar? Is there anything else I can do to > > get more information here; e.g. are there builds of Cygwin with debug > > symbols published somewhere, or should I try producing my own debug > > build? > > Well, you could have mentioned that this is on AArch64. Fortunately > you did in the github case, but next time, please tell us here, too. > > I assume you can't run any Cygwin binary, even from outside the > installer? > > Other than that, the only thing you really could do at this point is to > check Cygwin's find_fast_cwd_pointer() function and go through this > function step by step, diving into the assembler code this function > inspects trying to find out which of the memmem calls fails and how to > fix it. And send a patch eventually. > > However, there isn't much point there as long as this is an insider > build. In the past, the code often changed and was uncritical in the > next official release. > > One thing we can do is to skip the find_fast_cwd_pointer() code entirely > when running on AArch64, but it's a bit annoying, given this wasn't > necessary in previous AArch64 builds. I've just pushed a (temporary?) patch to do just that. This will be in the test build cygwin-3.6.0-0.37.g4e77fa9b8bf4 which will be installable via Cygwin's installer in an hour or two. Please try if this works for you and report back. You can use this DLL as workaround for the time being then. 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
Re: Cygwin installer hangs when running post-install scripts
On Feb 12 14:38, Kevin Ushey via Cygwin wrote: > Hello, > > I'm seeing an issue when attempting to install Cygwin where the > installer hangs while trying to run postinstall scripts (more > specifically, /etc/postinstall/0p_000_autorebase.dash). When the hang > occurs, I see a 'dash.exe' process chewing up 100% of a CPU. If I > attach to the process with WinDbg, I see: > > (940.978): Access violation - code c005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > cygwin1!memmem+0xcb: > 7ffa`490cbb1b 410fb60424 movzx eax,byte ptr [r12] > ds:7ffa`552651f7=?? > 0:000> k > # Arch Child-SP RetAddr Call Site > 00AMD64 0007`c930 7ffa`48f8028f cygwin1!memmem+0xcb > 01AMD64 0007`ca90 7ffa`48f80a49 > cygwin1!cygwin_split_path+0x3a0 > 02AMD64 0007`cb20 7ffa`48f37071 > cygwin1!cygwin_split_path+0xb5a > 03AMD64 0007`cc50 7ffa`48f35e08 > cygwin1!cygwin_dll_init+0x26b > 04AMD64 0007`cd80 7ffa`48f35e86 cygwin1!_assert+0x23f0 > 05AMD64 0007`cdd0 ` cygwin1!_assert+0x246e > > I'm not sure how much I can trust the stack trace here, though. I don't think this stacktrace makes any sense. cygwin_split_path is a function only exported for historical reasons and not used internally. Dash doesn't call it either. > For reference, I first bumped into this when using Git Bash as bundled > with Git for Windows, but it sounds like the underlying issue may be > in Cygwin. See https://github.com/git-for-windows/git/issues/4808 for > more details. There is, however, the stacktrace from your above issue report on github, which makes more sense, and, incidentally, occurs in code following cygwin_split_path in the .text segment: (gdb) bt #0 0x0002101eeaf3 in memmem () from [...] #1 0x000210095d91 in cwdstuff::override_win32_cwd(bool, unsigned int) () from [...] #2 0x00021009642e in cwdstuff::set(path_conv*, char const*) () from [...] #3 0x000210047025 in dll_crt0_1(void*) () from [...] #4 [...] This points to something going wrong during startup, while trying to evaluate the global pointer to the hidden ntdll.dll struct we called, for want of an official expression, FAST_CWD structure. If we can rely on frame 1, a call to memmem crashes, that would mean the crash occurs in find_fast_cwd_pointer(). > Does any of this sound familiar? Is there anything else I can do to > get more information here; e.g. are there builds of Cygwin with debug > symbols published somewhere, or should I try producing my own debug > build? Well, you could have mentioned that this is on AArch64. Fortunately you did in the github case, but next time, please tell us here, too. I assume you can't run any Cygwin binary, even from outside the installer? Other than that, the only thing you really could do at this point is to check Cygwin's find_fast_cwd_pointer() function and go through this function step by step, diving into the assembler code this function inspects trying to find out which of the memmem calls fails and how to fix it. And send a patch eventually. However, there isn't much point there as long as this is an insider build. In the past, the code often changed and was uncritical in the next official release. One thing we can do is to skip the find_fast_cwd_pointer() code entirely when running on AArch64, but it's a bit annoying, given this wasn't necessary in previous AArch64 builds. 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
