Wineboot hangs forever

[2xsaiko]

As of recently, this Wine fork will fail to create new prefixes or update existing prefixes on my system, instead hanging forever even before the wineboot dialog comes up. This includes launching games using Proton inside of Steam, tested with Proton (as of 5/9/22) Experimental, older versions such as Proton 6.3-8 and 3.7-8 work. Initially I encountered this with another Wine fork based off of this one, wine-ge-custom but the same problem occurs here as well, which makes sense since the bad commit (see below) is in both forks.

Bisecting the repository showed the first bad commit to be 90bc8ed, and reverting it fixes the issue (though obviously I don't want to build my own Proton versions).

Here's a log of me running wine with WINEDEBUG=all, it's pretty long so I couldn't upload it here: https://dblsaiko.net/pub/tmp/wine-log.txt (this is using that other Wine fork, I can make one with this one if needed). The 0024: *killed* exit_code=1 and so on at the very end comes from me eventually running wineserver -k, it does not get killed if you keep it running.

Operating System: Gentoo Linux 2.8
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.93.0
Qt Version: 5.15.3
Kernel Version: 5.17.5-gentoo-dist (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor
Memory: 23.5 GiB of RAM
Graphics Processor: AMD Radeon RX Vega

[cyj0912]

From my debugging it seems like fshack has a deadlocking issue. This is causing rundll32 to hang when doing "Wow64Install" upon booting. Because wineboot waits on this install process, this caused the booting process to hang.

Stack trace is attached here: https://gist.github.com/cyj0912/af12f5d58ceca01fa08253f03e77f1d5

As you can see, fs_get_gpus is trying to lock the mutex. However, earlier on the stack, fs_hack_rect_user_to_real already holds the lock.

Turning this lock into a recursive mutex solves the issue.

[ivyl]

Hi @cyj0912 . What environment are you running this on? The deadlock seems to happen because winex11.drv's settings_handler is nores which should not be the case. Before we initialize fshack we try to also load xrandr and libXxf86vm which replaces that handler with something that does not deadlock.

My guess is that you are building your own version of Proton without having libxrandr-dev installed or you try to run it outside of stream runtime container without having libxrandr installed.

@2xsaiko that may be also the case for you - you are compiling Proton without some libs that we assume to be present.

I don't think we have the capacity to support usecases outside of steam runtime actively but we could at least make those libraries mandatory during ./configure.

[cyj0912]

Hi @ivyl, thanks a lot for the insight. Missing libxrandr on the host was indeed the issue (only x64 binary was installed).

[2xsaiko]

I don't have that system anymore, but it lacking 32-bit libxrandr would make sense.

[cyj0912]

From my perspective this bug can be closed as WNF.

…

________________________________ From: Marco Rebhan ***@***.***> Sent: Saturday, October 14, 2023 2:47:18 AM To: ValveSoftware/wine ***@***.***> Cc: Toby Chen ***@***.***>; Mention ***@***.***> Subject: Re: [ValveSoftware/wine] Wineboot hangs forever (Issue #147) I don't have that system anymore, but it lacking 32-bit libxrandr would make sense. — Reply to this email directly, view it on GitHub<#147 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAM4AGU43OLQPGBRCR4YLYLX7GEDNAVCNFSM5VO22AR2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZWGIYDGMJUGQ3A>. You are receiving this because you were mentioned.Message ID: ***@***.***>