[Bug 59617] New: wineboot times out and does not copy any system dll (all versions after 10.2, including)
http://bugs.winehq.org/show_bug.cgi?id=59617 Bug ID: 59617 Summary: wineboot times out and does not copy any system dll (all versions after 10.2, including) Product: Wine Version: 10.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs@list.winehq.org Reporter: otigkd@gmail.com Distribution: --- Created attachment 80678 --> http://bugs.winehq.org/attachment.cgi?id=80678 output of winecfg/wineboot Noticed this last year on all my gentoo machines (the setup on all of them is almost identical: X + Xfce and NO wayland): On a fresh first run either wineboot or winecfg hangs for a rather long time, then fails with the status c0000135 (STATUS_DLL_NOT_FOUND) I have spent a lot of time last year, to find the source of the problem, at first i thought this was a gentoo issue: wine stopped working, when the gentoo ebuilds first got the "X" and "wayland" use flags. An old 10.0 installation still works on my machine, but i would like to update to newer versions, so i decided to find at least the version, that broke it on my machine. After checking out wine (vanilla, NOT staging), and building it and trying to run notepad, I have narrowed it down to the 10.2 release: - wine-10.0: works - wine-10.1: works - wine-10.2: does NOT work - wine-10.3: does NOT work - wine-10.6: does NOT work - wine-10.10: does NOT work I also tried to do a diff between the 2 tags, but there a hundreds of commits to try to rebuild and test them individually. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 otigkd@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |otigkd@gmail.com Distribution|--- |Gentoo -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 Bernhard Übelacker <bernhardu@mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org --- Comment #1 from Bernhard Übelacker <bernhardu@mailbox.org> --- Hello, is this issue also still visible in more recent wine versions like wine-11.5? Is the attached file when starting with a fresh .wineprefix? Maybe you can please attach a log generated like this: WINEDEBUG=+pid,+seh,+loaddll,+module wine winecfg 2>&1 | tee 59617+pid,+seh,+loaddll,+module.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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #2 from otigkd@gmail.com --- (In reply to Bernhard Übelacker from comment #1)
Hello, is this issue also still visible in more recent wine versions like wine-11.5?
Yes. Throughout the year i always updated my wine installation in hopes, that it gets fixed, but none worked after this version.
Is the attached file when starting with a fresh .wineprefix?
Yes, I always deleted the previous version's .wine directory before trying.
Maybe you can please attach a log generated like this:
WINEDEBUG=+pid,+seh,+loaddll,+module wine winecfg 2>&1 | tee 59617+pid,+seh,+loaddll,+module.log
Will do -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #3 from otigkd@gmail.com --- Created attachment 80680 --> http://bugs.winehq.org/attachment.cgi?id=80680 wine-11.5 (Staging) winecfg log latest wine staging (11.5), maintaned by gentoo: https://gitweb.gentoo.org/repo/gentoo.git/tree/app-emulation/wine-staging/wi... -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #4 from Bernhard Übelacker <bernhardu@mailbox.org> --- (In reply to otigkd from comment #3)
Created attachment 80680 [details] wine-11.5 (Staging) winecfg log
Do you even get the small window shown about "The Wine configuration in ... is being updated"? The lines "seh:handle_syscall_fault code=c0000005" for PIDs 0048 and 0050 seem to belong to explorer.exe processes. Can you please repeat this with this WINEDEBUG: WINEDEBUG=+pid,+seh,+loaddll,+module,+timestamp,+wineboot,+explorer -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #5 from otigkd@gmail.com --- (In reply to Bernhard Übelacker from comment #4)
(In reply to otigkd from comment #3)
Created attachment 80680 [details] wine-11.5 (Staging) winecfg log
Do you even get the small window shown about "The Wine configuration in ... is being updated"?
No
The lines "seh:handle_syscall_fault code=c0000005" for PIDs 0048 and 0050 seem to belong to explorer.exe processes.
Can you please repeat this with this WINEDEBUG: WINEDEBUG=+pid,+seh,+loaddll,+module,+timestamp,+wineboot,+explorer
Will do -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #6 from otigkd@gmail.com --- Created attachment 80681 --> http://bugs.winehq.org/attachment.cgi?id=80681 WINEDEBUG=+pid,+seh,+loaddll,+module,+timestamp,+wineboot,+explorer wine winecfg 2>&1 | tee 59617+pid,+seh,+loaddll,+module.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.
http://bugs.winehq.org/show_bug.cgi?id=59617 Austin English <austinenglish@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression --- Comment #7 from Austin English <austinenglish@gmail.com> --- Please run a regression test: https://gitlab.winehq.org/wine/wine/-/wikis/Regression-Testing -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #8 from otigkd@gmail.com --- Created attachment 80685 --> http://bugs.winehq.org/attachment.cgi?id=80685 regression test result -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 otigkd@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |e3c7c5c86b0bf426dc37af965ae | |5a08f6908998e -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 Austin English <austinenglish@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman@codeweavers.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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #9 from Paul Gofman <pgofman@codeweavers.com> --- This is strange. It is not like Wine is broken for everyone since then (or, anyone else this way, as far as reports known by me go), so there must be something specific to the setup which is either a core problem or triggers some real bug (which so far I don't have info to guess). One weak guess is that maybe there is some wrongly set up (or in some way special) Vulkan device / driver in host configuration for which vkGetPhysicalDeviceProperties2KHR crashes for some reason, but before the patch it was not called because vkGetRandROutputDisplayEXT was failing for it without crashing. But even if that is the case I cannot fix it without understanding what is actually going on (and maybe it is not a Wine bug even). First of all, the log is not from upstream Wine and thus the issue may potential be caused by other unknown patches:
40916.439:0020:0024:trace:module:hidden_exports_init getting default HideWineExports
There are also other things in the log which look a bit weird to me at the first glance. Before anything else, could you please check if the issue persists with current upstream Wine, without any custom patches on top? If it does, may I ask for the following additional info: 1. The resulting vulkaninfo.txt from 'vulkaninfo >&vulkaninfo.txt' ('>&' is there to also see the warnings it might print to stderr). 2. Output of xrandr, xrandr --listproviders and xrandr --listmonitors 3. Full command line how Wine is being run. 4. A compressed log with the failure from current upstream Wine with WINEDEBUG=+pid,+seh,+timestamp,+syscall,+unwind,+loaddll,+module,win,+explorer,+win,+x11drv,+event,+xrandr . The log may be rather big but should compress very well. 5. Attach Wine's <winebinpath>/lib/wine/x86_64-windows/win32u.dll <winebinpath>/lib/wine/x86_64-unix/win32u.so from the build which reproduces the issue. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #10 from Paul Gofman <pgofman@codeweavers.com> --- Sorry, for the log in p. 4, I forgot +system, and '+' before win: WINEDEBUG=+pid,+seh,+timestamp,+syscall,+unwind,+loaddll,+module,+win,+explorer,+win,+x11drv,+system,+event,+xrandr -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #11 from Bernhard Übelacker <bernhardu@mailbox.org> --- Hello otigkd, additional to the outputs Paul asked for, there may be another way to get a backtrace of this crash. Maybe you can pick the top three patches from this branch: https://gitlab.winehq.org/bernhardu/wine/-/commits/debug_59617_attachlinuxgd... And try to create a fresh wineprefix this way: WINEDEBUG=+attachlinuxgdb wine winecfg This should attach to each process, which loads winex11.drv, a system gdb in the background, which should create logfiles like gdb-wine-%d.log. In my tests these got created for explorer.exe processes in the directory $WINEPREFIX/drive_c/windows/system32. If we are lucky one of those files may show some information. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #12 from otigkd@gmail.com --- Created attachment 80703 --> http://bugs.winehq.org/attachment.cgi?id=80703 xrandr -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #13 from otigkd@gmail.com --- Created attachment 80704 --> http://bugs.winehq.org/attachment.cgi?id=80704 xrandr --listmonitors -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #14 from otigkd@gmail.com --- Created attachment 80705 --> http://bugs.winehq.org/attachment.cgi?id=80705 xrandr --listproviders -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #15 from otigkd@gmail.com --- Created attachment 80706 --> http://bugs.winehq.org/attachment.cgi?id=80706 win32u.dll -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #16 from otigkd@gmail.com --- Created attachment 80707 --> http://bugs.winehq.org/attachment.cgi?id=80707 win32u.so -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #17 from otigkd@gmail.com --- Created attachment 80708 --> http://bugs.winehq.org/attachment.cgi?id=80708 vulkaninfo -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #18 from otigkd@gmail.com --- Created attachment 80709 --> http://bugs.winehq.org/attachment.cgi?id=80709 ./wine winecfg with latest vanilla (5f5473e1037a7285619bb32b41091f503d8e9775) command line: WINEDEBUG=+pid,+seh,+timestamp,+syscall,+unwind,+loaddll,+module,+win,+explorer,+win,+x11drv,+system,+event,+xrandr ./wine winecfg >& /tmp/wine_logs/wine_winecfg.log.txt -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #19 from otigkd@gmail.com --- (In reply to Paul Gofman from comment #9)
This is strange. It is not like Wine is broken for everyone since then (or, anyone else this way, as far as reports known by me go), so there must be something specific to the setup which is either a core problem or triggers some real bug (which so far I don't have info to guess). One weak guess is that maybe there is some wrongly set up (or in some way special) Vulkan device / driver in host configuration for which vkGetPhysicalDeviceProperties2KHR crashes for some reason, but before the patch it was not called because vkGetRandROutputDisplayEXT was failing for it without crashing. But even if that is the case I cannot fix it without understanding what is actually going on (and maybe it is not a Wine bug even).
I kinda figured, that it might be because of my machine, but the strange things, that it repeats across 3 different devices (2 of them use nvidia proprietary drivers, 1 uses open-source AMDGPU) All the machines have 99% identical system: custom kernel, OpenRC, X (no wayland), Xfce
First of all, the log is not from upstream Wine and thus the issue may potential be caused by other unknown patches:
40916.439:0020:0024:trace:module:hidden_exports_init getting default HideWineExports
There are also other things in the log which look a bit weird to me at the first glance.
Before anything else, could you please check if the issue persists with current upstream Wine, without any custom patches on top?
If it does, may I ask for the following additional info: 1. The resulting vulkaninfo.txt from 'vulkaninfo >&vulkaninfo.txt' ('>&' is there to also see the warnings it might print to stderr).
done.
2. Output of xrandr, xrandr --listproviders and xrandr --listmonitors
done.
3. Full command line how Wine is being run.
added this as the description of the attachment
4. A compressed log with the failure from current upstream Wine with WINEDEBUG=+pid,+seh,+timestamp,+syscall,+unwind,+loaddll,+module,win, +explorer,+win,+x11drv,+event,+xrandr . The log may be rather big but should compress very well.
done.
5. Attach Wine's <winebinpath>/lib/wine/x86_64-windows/win32u.dll <winebinpath>/lib/wine/x86_64-unix/win32u.so from the build which reproduces the issue.
done - NOTE: I used the default build of ./configure and make, which apparently built only 32 bit? does not matter, as it reproduces the same way -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #20 from otigkd@gmail.com --- Created attachment 80710 --> http://bugs.winehq.org/attachment.cgi?id=80710 wine with custom patches terminal output of running: WINEDEBUG=+attachlinuxgdb ./wine winecfg with top 3 patches from: https://gitlab.winehq.org/bernhardu/wine/-/commits/debug_59617_attachlinuxgd... -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #21 from Paul Gofman <pgofman@codeweavers.com> --- Sorry, still no ideas so far. Maybe the way forward is to run with a debug patch on top with more logging, but for a start, the log is missing +system channel which can potentially narrow down the place where things go wrong. I forgot that in initial debug string but mentioned in the next comment. Could you please add such a log, with WINEDEBUG=+pid,+seh,+timestamp,+syscall,+unwind,+loaddll,+module,+win,+explorer,+win,+x11drv,+system,+event,+xrandr ? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #22 from otigkd@gmail.com --- Created attachment 80711 --> http://bugs.winehq.org/attachment.cgi?id=80711 gdb wine log 0 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #23 from otigkd@gmail.com --- Created attachment 80712 --> http://bugs.winehq.org/attachment.cgi?id=80712 gdb wine log 1 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #24 from otigkd@gmail.com --- (In reply to Bernhard Übelacker from comment #11)
Hello otigkd, additional to the outputs Paul asked for, there may be another way to get a backtrace of this crash.
Maybe you can pick the top three patches from this branch:
https://gitlab.winehq.org/bernhardu/wine/-/commits/debug_59617_attachlinuxgd...
And try to create a fresh wineprefix this way: WINEDEBUG=+attachlinuxgdb wine winecfg
This should attach to each process, which loads winex11.drv, a system gdb in the background, which should create logfiles like gdb-wine-%d.log. In my tests these got created for explorer.exe processes in the directory $WINEPREFIX/drive_c/windows/system32.
If we are lucky one of those files may show some information.
attached the 2 log files also attached the console output of said command -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #25 from Paul Gofman <pgofman@codeweavers.com> --- So I think the next step is add +system to previous logging (see https://bugs.winehq.org/show_bug.cgi?id=59617#c21). The attempt to add gdb with custom patches doesn't seem to show much, it jumped to NULL address from somewhere and it can't backtrace 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #26 from otigkd@gmail.com --- (In reply to Paul Gofman from comment #25)
So I think the next step is add +system to previous logging (see https://bugs.winehq.org/show_bug.cgi?id=59617#c21). The attempt to add gdb with custom patches doesn't seem to show much, it jumped to NULL address from somewhere and it can't backtrace it.
yes, sure, will try. just want to clarify a few things: Should I do the next run with or without the mentioned 3 patches - as mentioned in https://bugs.winehq.org/show_bug.cgi?id=59617#c11? (my current head is at https://gitlab.winehq.org/wine/wine/-/commit/5f5473e1037a7285619bb32b41091f5...) could you please also tell me the command line, to make sure, that nothing is omitted? - is the following okay (I'm running it from the directory, where wine is built, hence the ./wine): WINEDEBUG=+pid,+seh,+timestamp,+syscall,+unwind,+loaddll,+module,+win,+explorer,+win,+x11drv,+system,+event,+xrandr ./wine winecfg > wine_winecfg.log.txt 2>&1 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #27 from Paul Gofman <pgofman@codeweavers.com> ---
Should I do the next run with or without the mentioned 3 patches - as mentioned in https://bugs.winehq.org/show_bug.cgi?id=59617#c11? (my current head is at https://gitlab.winehq.org/wine/wine/-/commit/ 5f5473e1037a7285619bb32b41091f503d8e9775)
without any extra patches. Depending on what we see with added log, maybe I will send a patch which just adds more debug logging.
could you please also tell me the command line, to make sure, that nothing is omitted? - is the following okay (I'm running it from the directory, where wine is built, hence the ./wine):
WINEDEBUG=+pid,+seh,+timestamp,+syscall,+unwind,+loaddll,+module,+win, +explorer,+win,+x11drv,+system,+event,+xrandr ./wine winecfg > wine_winecfg.log.txt 2>&1
Command looks fine. Could you also please remove the Wine prefix entirely before each run. With such a command it is /home/user/.wine directory, you may also use WINEPREFIX=/full/path to place the prefix in the specified 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 otigkd@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #80709|0 |1 is obsolete| | --- Comment #28 from otigkd@gmail.com --- Created attachment 80714 --> http://bugs.winehq.org/attachment.cgi?id=80714 WINEDEBUG=+pid,+seh,+timestamp,+syscall,+unwind,+loaddll,+module,+win,+explorer,+win,+x11drv,+system,+event,+xrandr ./wine winecfg > wine_winecfg.log.txt 2>&1 added +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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #29 from otigkd@gmail.com --- (In reply to Paul Gofman from comment #27)
Should I do the next run with or without the mentioned 3 patches - as mentioned in https://bugs.winehq.org/show_bug.cgi?id=59617#c11? (my current head is at https://gitlab.winehq.org/wine/wine/-/commit/ 5f5473e1037a7285619bb32b41091f503d8e9775)
without any extra patches. Depending on what we see with added log, maybe I will send a patch which just adds more debug logging.
could you please also tell me the command line, to make sure, that nothing is omitted? - is the following okay (I'm running it from the directory, where wine is built, hence the ./wine):
WINEDEBUG=+pid,+seh,+timestamp,+syscall,+unwind,+loaddll,+module,+win, +explorer,+win,+x11drv,+system,+event,+xrandr ./wine winecfg > wine_winecfg.log.txt 2>&1
Command looks fine. Could you also please remove the Wine prefix entirely before each run. With such a command it is /home/user/.wine directory, you may also use WINEPREFIX=/full/path to place the prefix in the specified directory. I always deleted the .wine directory (used the default one in ~/)
Attached results -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #30 from Paul Gofman <pgofman@codeweavers.com> --- Created attachment 80715 --> http://bugs.winehq.org/attachment.cgi?id=80715 debug logging So nothing new... I am attaching a patch which adds logging around native calls where it is maybe crashing... could you please redo the log with this patch and the same logging channels as last time? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 otigkd@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #80714|0 |1 is obsolete| | --- Comment #31 from otigkd@gmail.com --- Created attachment 80716 --> http://bugs.winehq.org/attachment.cgi?id=80716 new log with debug patch Added new 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #32 from otigkd@gmail.com --- Created attachment 80717 --> http://bugs.winehq.org/attachment.cgi?id=80717 directory tree of ~/.wine Don't know, if I forgot to mention - seeing all those STATUS_OBJECT_NAME_NOT_FOUND (c0000034) ALL of the directories, where the .dlls should be in ~/.wine are empty. If i forgot to mention it in the first place, sorry. I already asked this question in the gentoo forums (https://forums.gentoo.org/viewtopic.php?t=1175453), and there I included this information -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #33 from Paul Gofman <pgofman@codeweavers.com> --- (In reply to otigkd from comment #31)
Created attachment 80716 [details] new log with debug patch
Added new log
So it crashes inside host Vulkan library vkGetRandROutputDisplayEXT call (and our pointer to that is not NULL, debug output prints that). I can see how that could change with the patch, it apparently crashes when called for NVidia device with xrandr output 0 and before the patch it was first called with Intel device, that wasn't crashing and was reporting the connection between those and another call for vkGetRandROutputDisplayEXT( NVidia / xrandr output 0 ) was never made. One weird thing I noticed is that xrandr output linked above reports two connections (probably for the same 1920x1200 monitor), on eDP-1 and DP-1. Is there any special / manual in monitor confifuration? But that can also be not a problem and just specifics of the particular Optimus setup. That looks like either NVidia drivers bug or host configuration problem. I am not sure we can do anything reasonable if the call to vkGetRandROutputDisplayEXT just crashes (not even gives X error as it was happening once with NV driver and for such a behaviour we temporary had a workaround). -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #34 from Bernhard Übelacker <bernhardu@mailbox.org> --- (In reply to otigkd from comment #32)
Created attachment 80717 [details] directory tree of ~/.wine
Don't know, if I forgot to mention - seeing all those STATUS_OBJECT_NAME_NOT_FOUND (c0000034) ALL of the directories, where the .dlls should be in ~/.wine are empty.
I guess the interesting parts are the "handle_syscall_fault code=c0000005". Therefore the explorer.exe processes crash.
If i forgot to mention it in the first place, sorry. I already asked this question in the gentoo forums (https://forums.gentoo.org/viewtopic.php?t=1175453), and there I included this information
And because the explorer.exes did not startup properly the wineboot never gets to the point to fill the wineprefix with all files. Thanks for testing the gdb approach, I did test only a simple memory access to NULL, but because of the function call to zero the information is very limited. Additionally the libc.so debug information looks also not complete. And gdb seems quite unhappy with this setup, because it was not able to list all shared objects, where I would have expected some nvidia libraries from your latest findings with Pauls instructions. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #35 from otigkd@gmail.com --- (In reply to Paul Gofman from comment #33)
(In reply to otigkd from comment #31)
Created attachment 80716 [details] new log with debug patch
Added new log
So it crashes inside host Vulkan library vkGetRandROutputDisplayEXT call (and our pointer to that is not NULL, debug output prints that). I can see how that could change with the patch, it apparently crashes when called for NVidia device with xrandr output 0 and before the patch it was first called with Intel device, that wasn't crashing and was reporting the connection between those and another call for vkGetRandROutputDisplayEXT( NVidia / xrandr output 0 ) was never made.
One weird thing I noticed is that xrandr output linked above reports two connections (probably for the same 1920x1200 monitor), on eDP-1 and DP-1. Is there any special / manual in monitor confifuration? But that can also be not a problem and just specifics of the particular Optimus setup.
all 3 machines, where i have gentoo with this issue have a few things in common (as mentioned before, the issue reproduces on all of them, regardless if the open-source AMDGPU is in use or the closed-source nvidia): - all of them are notebooks, with integrated corei7 GPUs and dedicated AMD or nvidia GPU - all of them are used as "desktop" machines: lid closed, mouse and keyboard connected - dedicated GPU acceleration is not on by default, meaning i have to do "DRI_PRIME=1 [application name]" on the AMD machines and "prime-run [application name]" on the nvidia machines to have the application be run trough the dedicated card, instead of the integrated Since I like doing things manually, nvidia optimus and such are turned off. Out of curiosity, I tried to run a winecfg with the external monitor disconnected, using the notebook's own monitor, but the issue reproduces the same.
That looks like either NVidia drivers bug or host configuration problem. I am not sure we can do anything reasonable if the call to vkGetRandROutputDisplayEXT just crashes (not even gives X error as it was happening once with NV driver and for such a behaviour we temporary had a workaround).
Most likely a configuration problem, but it's really strange as absolutely no other game/application has this issue, be it native linux application or any game on older wine, that i could run -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #36 from Bernhard Übelacker <bernhardu@mailbox.org> --- Don't know if this is of any help, but I tried to find a way to force usage of software rendering by using these environments: LIBGL_ALWAYS_SOFTWARE=1 __GLX_VENDOR_LIBRARY_NAME=mesa VK_DRIVER_FILES=/usr/share/vulkan/icd.d/lvp_icd.json wine winecfg Unfortunately that crashes here with Debian trixie, also with eglinfo, but maybe Gentoo has already a newser library stack. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #37 from otigkd@gmail.com --- (In reply to Bernhard Übelacker from comment #36)
Don't know if this is of any help, but I tried to find a way to force usage of software rendering by using these environments: LIBGL_ALWAYS_SOFTWARE=1 __GLX_VENDOR_LIBRARY_NAME=mesa VK_DRIVER_FILES=/usr/share/vulkan/icd.d/lvp_icd.json wine winecfg
Unfortunately that crashes here with Debian trixie, also with eglinfo, but maybe Gentoo has already a newser library stack.
Sadly forcing software rendering would defeat the whole purpose, as the games need hardware acceleration. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #38 from Paul Gofman <pgofman@codeweavers.com> --- Created attachment 80721 --> http://bugs.winehq.org/attachment.cgi?id=80721 Linux native test program I made a native test program to poke this outside of Wine. This is heavily based on WIne's winex11 code but works a standalone program for test. Could you please compile it and run (both 64 and 32 bit version). To compile: 64 bit: gcc -O2 -Wall test.c -lXext -lX11 -lpthread -o xr_vulk_test 32 bit: gcc -m32 -O2 -Wall test.c -lXext -lX11 -lpthread -o xr_vulk_test32 Then run ./xr_vulk_test and ./xr_vulk_test32, on exact same terminal where your Wine run fails. First interesting thing is whether that crash or not. If that crashes, could you please run that with gdb ./xr_vulk_test (agree to download debug info if it asks so). Inside gdb, type 'run'. it should stop with SIGSEGV, and then backtrace command might print an interesting output. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #39 from otigkd@gmail.com --- Created attachment 80724 --> http://bugs.winehq.org/attachment.cgi?id=80724 xr_vulk_test_64 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #40 from otigkd@gmail.com --- Created attachment 80725 --> http://bugs.winehq.org/attachment.cgi?id=80725 xr_vulk_test_32 output -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 otigkd@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #80724|xr_vulk_test_64 |xr_vulk_test_64 output description| | -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #41 from otigkd@gmail.com --- Created attachment 80726 --> http://bugs.winehq.org/attachment.cgi?id=80726 gdb ./xr_vulk_test_64 no debugging symbols. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #42 from otigkd@gmail.com --- (In reply to Paul Gofman from comment #38)
Created attachment 80721 [details] Linux native test program
I made a native test program to poke this outside of Wine. This is heavily based on WIne's winex11 code but works a standalone program for test.
Could you please compile it and run (both 64 and 32 bit version). To compile: 64 bit: gcc -O2 -Wall test.c -lXext -lX11 -lpthread -o xr_vulk_test 32 bit: gcc -m32 -O2 -Wall test.c -lXext -lX11 -lpthread -o xr_vulk_test32
Then run ./xr_vulk_test and ./xr_vulk_test32, on exact same terminal where your Wine run fails. First interesting thing is whether that crash or not. If that crashes, could you please run that with gdb ./xr_vulk_test (agree to download debug info if it asks so). Inside gdb, type 'run'. it should stop with SIGSEGV, and then backtrace command might print an interesting output.
Crashes kinda obviously :( Attached output and gdb output. Can try again with debug symbols for nvidia-drivers package too -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #43 from otigkd@gmail.com --- (In reply to Bernhard Übelacker from comment #36)
Don't know if this is of any help, but I tried to find a way to force usage of software rendering by using these environments: LIBGL_ALWAYS_SOFTWARE=1 __GLX_VENDOR_LIBRARY_NAME=mesa VK_DRIVER_FILES=/usr/share/vulkan/icd.d/lvp_icd.json wine winecfg
Unfortunately that crashes here with Debian trixie, also with eglinfo, but maybe Gentoo has already a newser library stack.
Installed lavapipe and tried to run again (LIBGL_ALWAYS_SOFTWARE=1 __GLX_VENDOR_LIBRARY_NAME=mesa VK_DRIVER_FILES=/usr/share/vulkan/icd.d/lvp_icd.i686.json ./wine winecfg), but got the same error: libEGL warning: Not allowed to force software rendering when API explicitly selects a hardware device. libEGL warning: Not allowed to force software rendering when API explicitly selects a hardware device. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #44 from otigkd@gmail.com --- Created attachment 80727 --> http://bugs.winehq.org/attachment.cgi?id=80727 prime-run ./xr_vulk_test_64 tried with prime-run too -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #45 from otigkd@gmail.com --- Sadly it seems, that the crash is in nvidia proprietary code. will try it on am AMD machine to see if that has a different effect -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #46 from Paul Gofman <pgofman@codeweavers.com> --- Yes the similar thing (Wine and this standalone test) from an AMD machine would be interesting. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #47 from otigkd@gmail.com --- Created attachment 80756 --> http://bugs.winehq.org/attachment.cgi?id=80756 xr_vulk_test 64 - AMD GPU does not crash -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #48 from otigkd@gmail.com --- Created attachment 80757 --> http://bugs.winehq.org/attachment.cgi?id=80757 xr_vulk_test 32 - AMD GPU does not crash -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 --- Comment #49 from otigkd@gmail.com --- (In reply to Paul Gofman from comment #46)
Yes the similar thing (Wine and this standalone test) from an AMD machine would be interesting.
Done the test. Sadly it does not crash - now I am pretty sure I was misremembering, and I never encountered this on the AMD machine. So it seems it's more likely an nvidia issue -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59617 Paul Gofman <pgofman@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|UNCONFIRMED |RESOLVED --- Comment #50 from Paul Gofman <pgofman@codeweavers.com> --- So this looks like either bug in NVidia driver or something on that machine config triggering that. I don't think we have any good way to fix that: when previously we were handling X error that was different; if the thing just gives SEGFAULT inside the driver catching that and continuing as nothing happened is not great, it leaves things in undefined state in the driver and may exhibit as instability or hangs later. I think this should be reported to NVidia if problems in the setup cannot be found (and standalone sample may be used for that reporting). Resolving as NOTOURBUG. -- 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