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 #2 0x00007ffa0123bb7d in find_fast_cwd () at ../../../../winsup/cygwin/path.cc:4614 #3 0x00007ffa0123fd39 in cwdstuff::override_win32_cwd (this=this@entry=0x800004840, init=init@entry=true, old_dismount_count=old_dismount_count@entry=0) at ../../../../winsup/cygwin/path.cc:4649 #4 0x00007ffa0124035c in cwdstuff::set (this=0x800004840, nat_cwd=nat_cwd@entry=0x0, posix_cwd=posix_cwd@entry=0x0) at ../../../../winsup/cygwin/path.cc:4999 #5 0x00007ffa012404fb in cwdstuff::init (this=<optimized out>) at ../../../../winsup/cygwin/path.cc:4739 #6 0x00007ffa011f78bd in dll_crt0_1 () at ../../../../winsup/cygwin/dcrt0.cc:839 #7 0x00007ffa011f5c5f in _cygtls::call2 (this=0x7ffffce00, func=0x7ffa011f782b <dll_crt0_1(void*)>, arg=0x0, buf=buf@entry=0x7ffffcdc0) at ../../../../winsup/cygwin/cygtls.cc:41 #8 0x00007ffa011f5ccc in _cygtls::call (func=<optimized out>, arg=<optimized out>) at ../../../../winsup/cygwin/cygtls.cc:28 #9 0x00007ffa011f72f1 in _dll_crt0 () at ../../../../winsup/cygwin/dcrt0.cc:1052 #10 0x0000000000000000 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) info locals ntdll = <optimized out> get_dir = <optimized out> ent_crit = 0x7ffa885a4b70 "H\213\304H\211X U]\351\342\214\030" rcall = 0x7ffa885a51cb <incomplete sequence \350\044> use_cwd = 0x7ffa552651f4 <error: Cannot access memory at address 0x7ffa552651f4> movrbx = <optimized out> lock = <optimized out> testrbx = <optimized out> 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 <corinna-cyg...@cygwin.com> 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 + 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
