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 <corinna-cyg...@cygwin.com> 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 0x00000002101eeaf3 in memmem () from [...] > > #1 0x0000000210095d91 in cwdstuff::override_win32_cwd(bool, unsigned int) > > () > > from [...] > > #2 0x000000021009642e in cwdstuff::set(path_conv*, char const*) () from > > [...] > > #3 0x0000000210047025 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
