Mail Archives: cygwin/2024/02/13/05:10:46
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 c0000005 (first chance)
> First chance exceptions are reported before any exception handling.
> This exception may be expected and handled.
> cygwin1!memmem+0xcb:
> 00007ffa`490cbb1b 410fb60424 movzx eax,byte ptr [r12]
> ds:00007ffa`552651f7=??
> 0:000> k
> # Arch Child-SP RetAddr Call Site
> 00 AMD64 00000007`ffffc930 00007ffa`48f8028f cygwin1!memmem+0xcb
> 01 AMD64 00000007`ffffca90 00007ffa`48f80a49
> cygwin1!cygwin_split_path+0x3a0
> 02 AMD64 00000007`ffffcb20 00007ffa`48f37071
> cygwin1!cygwin_split_path+0xb5a
> 03 AMD64 00000007`ffffcc50 00007ffa`48f35e08
> cygwin1!cygwin_dll_init+0x26b
> 04 AMD64 00000007`ffffcd80 00007ffa`48f35e86 cygwin1!_assert+0x23f0
> 05 AMD64 00000007`ffffcdd0 00000000`00000000 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 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.
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
- Raw text -