[Bug 54317] New: Change to exec_wineloader made wine not start at all
https://bugs.winehq.org/show_bug.cgi?id=54317 Bug ID: 54317 Summary: Change to exec_wineloader made wine not start at all Product: Wine Version: 8.0-rc4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hibbsncc1701(a)gmail.com Distribution: --- Attempting to start wine with a pre-existing prefix results in a failure to load ntdll / kernel32. With messages like "wine: could not load kernel32.dll, status c0000135" and 002c:err:module:load_wow64_ntdll failed to load L"\\??\\C:\\windows\\system32\\ntdll.dll" error 4000000e wine: Unhandled page fault on execute access to 00000000 at address 00000000 (thread 002c), starting debugger... being printed in the console. Wine then attempts to start winedbg only to get stuck in a forkbomb. Where winedbg won't start, triggering an exception, which will cause another attempt to start winedbg. At a rate of about 4-5 attempts a second. Attempting to ctrl-c it doesn't work, and requires manually terminating all of wine's processes. (Of which are numerous as wine will also attempt to start conhost.exe for each winedbg it attempts to load. None of which will terminate on their own.) Attempting to start wine with a fresh prefix results in an incomplete prefix directory. (Only the dosdevices / windows directories, and registry hives are present in the prefix. Of those windows is empty save for the syswow64 and system32 directories of which both are completely empty.) Attempting to start that prefix again causes the same winedbg behavior as above. Performing a bisect revealed: $ git bisect bad d45de318748639cfd1e80a976b39f5e19213990f is the first bad commit commit d45de318748639cfd1e80a976b39f5e19213990f Author: Alexandre Julliard <julliard(a)winehq.org> Date: Tue Nov 22 12:08:19 2022 +0100 ntdll: Always set WINELOADER variable to the current loader name. dlls/ntdll/unix/env.c | 3 +++ dlls/ntdll/unix/loader.c | 48 +++++++++++++++++++++--------------------------- 2 files changed, 24 insertions(+), 27 deletions(-) Reverting d45de318748639cfd1e80a976b39f5e19213990f fixed the issue on my system. -- 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=54317 Patrick Hibbs <hibbsncc1701(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |d45de318748639cfd1e80a976b3 | |9f5e19213990f -- 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=54317 --- Comment #1 from Alexandre Julliard <julliard(a)winehq.org> --- Is there anything peculiar about your setup? How are you building and running Wine? -- 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=54317 --- Comment #2 from Patrick Hibbs <hibbsncc1701(a)gmail.com> --- (In reply to Alexandre Julliard from comment #1)
Is there anything peculiar about your setup? How are you building and running Wine?
I build wine as per the Shared WoW64 section of the wiki. I don't need to use a chroot nor container, but I do wind up building wine three times to get a functional build. (wine64 -> winetools -> wine32) I also have configure set to use a custom installation prefix under /opt. After that I use update-alternatives for wine's main binaries (wine, wine32/64, wine-preloader/64, winecfg, explorer, msiexec, etc.) so that they can be found on the local $PATH, and so that I can switch them out seamlessly if I need to. (Makes testing regressions or other things easier for me.) This winds up putting about two layers of symlinks between where ever the $PATH search found wine and the actual installation directory, but I haven't had an issue with wine loading before now. Normally, If I'm testing something, I do so manually from the shell prompt. I.e. "WINEPREFIX=/path/to/some/new/prefix winecfg" but once things are stable and I know the prefix to be functional it gets moved to using a shell script I wrote to manage things. (Mostly save game / user data management, but it's also used by .desktop files and the other end users I have to manage wine for. (Copying the prefixes to their own directories.)) That said if something breaks I will try to test and re-create the prefix manually before coming here with it. -- 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=54317 --- Comment #3 from Alexandre Julliard <julliard(a)winehq.org> --- The symlinks sound like a possible culprit. Does it work if you run the wine binary directly? -- 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=54317 --- Comment #4 from Patrick Hibbs <hibbsncc1701(a)gmail.com> --- Created attachment 73902 --> https://bugs.winehq.org/attachment.cgi?id=73902 wrong bitness direct launch attempt log Calling wine directly doesn't work if the wrong bitness version of wine (E.g. wine32 for a 64bit winecfg) is used. -- 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=54317 --- Comment #5 from Patrick Hibbs <hibbsncc1701(a)gmail.com> --- Created attachment 73903 --> https://bugs.winehq.org/attachment.cgi?id=73903 correct bitness direct launch attempt log (In reply to Alexandre Julliard from comment #3)
The symlinks sound like a possible culprit. Does it work if you run the wine binary directly?
Using the correct bitness version of wine (E.g. wine64 with a 64bit winecfg) gets us a little bit further. I.e. Wine doesn't cause a forkbomb, and does create a virtual desktop window (if the prefix was configured for it) but it still crashes being unable to load ntdll. -- 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=54317 --- Comment #6 from Alexandre Julliard <julliard(a)winehq.org> --- OK I see, the problem is that you have separate /opt/wine-git-build/wine32 and /opt/wine-git-build/wine64 install directories. For a proper WoW64 setup you are supposed to install both trees to the same directory. -- 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=54317 Patrick Hibbs <hibbsncc1701(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Patrick Hibbs <hibbsncc1701(a)gmail.com> --- (In reply to Alexandre Julliard from comment #6)
OK I see, the problem is that you have separate /opt/wine-git-build/wine32 and /opt/wine-git-build/wine64 install directories. For a proper WoW64 setup you are supposed to install both trees to the same directory.
Yeah, changing the install prefix to keep both in the same directory works without reverting the commit. -- 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=54317 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #8 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Closing WORKSFORME. -- 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