[Bug 54511] New: Cygwin installer hangs during postprocessing step
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(a)winehq.org Reporter: dark.shadow4(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54511 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://www.cygwin.com/setu | |p-x86_64.exe Keywords| |download -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54511 --- Comment #1 from Fabian Maurer <dark.shadow4(a)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" -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54511 Bernhard Übelacker <bernhardu(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu(a)mailbox.org --- Comment #2 from Bernhard Übelacker <bernhardu(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54511 Joel Holdsworth <joel(a)airwebreathe.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joel(a)airwebreathe.org.uk -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54511 --- Comment #3 from Fabian Maurer <dark.shadow4(a)web.de> --- Just tested with the MR you linked rebased on top of wine-9.11, and that doesn't help. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54511 Jinoh Kang <jinoh.kang.kr(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jinoh.kang.kr(a)gmail.com --- Comment #4 from Jinoh Kang <jinoh.kang.kr(a)gmail.com> --- Mind posting a WINEDEBUG=+server log? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54511 --- Comment #5 from Bernhard Übelacker <bernhardu(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54511 --- Comment #6 from Fabian Maurer <dark.shadow4(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54511 --- Comment #7 from Jinoh Kang <jinoh.kang.kr(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54511 manschwetus(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |manschwetus(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54511 --- Comment #8 from Jinoh Kang <jinoh.kang.kr(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54511 --- Comment #9 from Fabian Maurer <dark.shadow4(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54511 --- Comment #10 from Joel Holdsworth <joel(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla