Cygwin installer hangs when running post-install scripts

Kevin Ushey kevinushey@gmail.com
Tue Feb 13 23:48:13 GMT 2024


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


More information about the Cygwin mailing list