https://bugs.winehq.org/show_bug.cgi?id=54511
Bug ID: 54511 Summary: Cygwin installer hangs during postprocessing step Product: Wine Version: 8.1 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: dark.shadow4@web.de Distribution: ---
Install seems to go fine, but in the end it hangs when running C:\cygwin64\bin\dash.exe "/etc/postinstall/0p_000_autorebase.dash"
Both wineserver and dash.exe use about half a cpu core each, but nothing seems to happen. Comparing it to windows, that step should be fast.
Cygwin used to install fine, but even when downgrading wine I can't seem to get it to work, it all shows the same issue. So it's probably not a Wine regression.
https://bugs.winehq.org/show_bug.cgi?id=54511
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://www.cygwin.com/setu | |p-x86_64.exe Keywords| |download
https://bugs.winehq.org/show_bug.cgi?id=54511
--- Comment #1 from Fabian Maurer dark.shadow4@web.de --- Minimal sample to reproduce the hang:
cat > /tmp/test<<EOF Test EOF
Just install cygwin until it hangs, kill it, and then run it like wine "C:\cygwin64\bin\dash.exe" "c:\test.dash"
https://bugs.winehq.org/show_bug.cgi?id=54511
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #2 from Bernhard Übelacker bernhardu@mailbox.org --- This bug might be the same as discussed in bug #52105.
There is also a merge request open: https://gitlab.winehq.org/wine/wine/-/merge_requests/498
https://bugs.winehq.org/show_bug.cgi?id=54511
Joel Holdsworth joel@airwebreathe.org.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joel@airwebreathe.org.uk
https://bugs.winehq.org/show_bug.cgi?id=54511
--- Comment #3 from Fabian Maurer dark.shadow4@web.de --- Just tested with the MR you linked rebased on top of wine-9.11, and that doesn't help.
https://bugs.winehq.org/show_bug.cgi?id=54511
Jinoh Kang jinoh.kang.kr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jinoh.kang.kr@gmail.com
--- Comment #4 from Jinoh Kang jinoh.kang.kr@gmail.com --- Mind posting a WINEDEBUG=+server log?
https://bugs.winehq.org/show_bug.cgi?id=54511
--- Comment #5 from Bernhard Übelacker bernhardu@mailbox.org --- (In reply to Fabian Maurer from comment #3)
Just tested with the MR you linked rebased on top of wine-9.11, and that doesn't help.
Hello Fabian, I can observe the hang in /etc/postinstall/0p_000_autorebase.dash with vanilla wine-9.12.
And when I apply the currently 5 patches from the MR I don't get that hang, and the setup can continue to the finish installation dialog.
Maybe you can re-check?
https://bugs.winehq.org/show_bug.cgi?id=54511
--- Comment #6 from Fabian Maurer dark.shadow4@web.de --- Created attachment 76700 --> https://bugs.winehq.org/attachment.cgi?id=76700 +server log
I rebased the MR onto wine-9.12, and tried both a raw 64 bit (with new wow64) and a wine-biarch build. Both still have the hang.
Freshly downloaded https://www.cygwin.com/setup-x86_64.exe, using the first mirror (163.com)
I first let it install until the hang, then ran wineserver -k, then took the log until the hang, stopping it with wineserver -k again.
https://bugs.winehq.org/show_bug.cgi?id=54511
--- Comment #7 from Jinoh Kang jinoh.kang.kr@gmail.com --- I don't see anything special in the server log. Maybe the stack trace on hang could be more helpful, but I'm not sure.
https://bugs.winehq.org/show_bug.cgi?id=54511
manschwetus@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |manschwetus@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=54511
--- Comment #8 from Jinoh Kang jinoh.kang.kr@gmail.com --- At the point of hang, can you attach a debugger (e.g., x64dbg) and see where it's stuck?
If it's stuck in Nt*() syscall functions, can you try attaching gdb as well?
https://bugs.winehq.org/show_bug.cgi?id=54511
--- Comment #9 from Fabian Maurer dark.shadow4@web.de --- Created attachment 77413 --> https://bugs.winehq.org/attachment.cgi?id=77413 +relay logs
It's not really hanging like that, it constantly uses one full CPU core for both dash.exe and wineserver. I don't think attaching a debugger helps much.
I tried getting a +relay log, but this makes the issue disappear, which is weird. Unless I add a ntdll.* exclude, then the issue reappears. Both attached.
I can work around the issue by making GetProcAddress(<ntdll>, "RtlGetCurrentDirectory_U") return NULL.
In the relay log you can see the last thing that happens in the good.log is the same thing that tries calculating the "FAST_CWD pointer". When it fails it is good, but in the bad case that seems to hang forever.
https://bugs.winehq.org/show_bug.cgi?id=54511
--- Comment #10 from Joel Holdsworth joel@airwebreathe.org.uk --- GetProcAddress (ntdll, "RtlGetCurrentDirectory_U") is called here: https://github.com/openunix/cygwin/blob/master/winsup/cygwin/path.cc#L4167
...which is called from find_fast_cwd(): https://github.com/openunix/cygwin/blob/master/winsup/cygwin/path.cc#L4260
...which also contains the noisy "Cygwin WARNING:", and the fallback path.
It seems to fail right after this:
015c:Call KERNEL32.GetProcAddress(6fffffdd0000,6ffffe3f870d "RtlGetCurrentDirectory_U") ret=6ffffe1ef3a5 015c:Ret KERNEL32.GetProcAddress() retval=6fffffe1f9a1 ret=6ffffe1ef3a5 015c:Call KERNEL32.GetProcAddress(6fffffdd0000,6ffffe3f8726 "RtlEnterCriticalSection") ret=6ffffe1ef3b7 015c:Ret KERNEL32.GetProcAddress() retval=6fffffe418ea ret=6ffffe1ef3b7
...and immediately afterward gets stuck in a loop doing this:
015c:Call KERNEL32.VirtualQuery(700003c63f9d,7ffffb860,00000030) ret=6ffffe1bf5a7 015c:Ret KERNEL32.VirtualQuery() retval=00000030 ret=6ffffe1bf5a7 015c:Call KERNEL32.IsDebuggerPresent() ret=6ffffe1bf2d0 015c:Ret KERNEL32.IsDebuggerPresent() retval=00000000 ret=6ffffe1bf2d0 015c:Call KERNEL32.WaitForSingleObject(000000a0,ffffffff) ret=6ffffe2c9599 015c:Ret KERNEL32.WaitForSingleObject() retval=00000000 ret=6ffffe2c9599 015c:Call KERNEL32.ReleaseMutex(000000a0) ret=6ffffe219f9b 015c:Ret KERNEL32.ReleaseMutex() retval=00000001 ret=6ffffe219f9b 015c:Call KERNEL32.WriteFile(00000094,7ffffb720,000000b0,7ffffb70c,00000000) ret=6ffffe219e9c 015c:Ret KERNEL32.WriteFile() retval=00000001 ret=6ffffe219e9c 015c:Call KERNEL32.WaitForSingleObject(00000104,0000ea60) ret=6ffffe21a0f2 0168:Ret KERNEL32.ReadFile() retval=00000001 ret=6ffffe2193da 0168:Call KERNEL32.SetEvent(00000098) ret=6ffffe219088 0168:Ret KERNEL32.SetEvent() retval=00000001 ret=6ffffe219088 0168:Call KERNEL32.SetEvent(00000104) ret=6ffffe21900d 015c:Ret KERNEL32.WaitForSingleObject() retval=00000000 ret=6ffffe21a0f2 0168:Ret KERNEL32.SetEvent() retval=00000001 ret=6ffffe21900d 015c:Call KERNEL32.CloseHandle(00000104) ret=6ffffe21a100 0168:Call KERNEL32.ReadFile(00000090,00afcae0,000000b0,00afcacc,00000000) ret=6ffffe2193da 015c:Ret KERNEL32.CloseHandle() retval=00000001 ret=6ffffe21a100
Is this the loop of the crash handler trying to wait for a debugger to connect?: https://github.com/openunix/cygwin/blob/master/winsup/cygwin/exceptions.cc#L...
Both the cygwin and msys2 projects should be urged to remove this FAST_CWD stuff. It causes no end of problems.
-
WineHQ Bugzilla