I have a container that I periodically rebuild based on rawhide, and the wine 9 upgrade causes wine to go completely haywire and forkbomb the machine. It crashes after bringing my system load to 2000+ and launching millions of explorer.exe processes. (I recommend if you want to reproduce this, you use your ulimit's appropriately.) Reproducible: Always Steps to Reproduce: Minimal reproducer, using docker container: 1. Create an interactive temporary rawhide container: $ docker run --rm -it quay.io/fedora/fedora:rawhide 2. In the container, install wine: # dnf -y install wine 3. Try to run wineboot: # env WINEDEBUG=-all wineboot && printf '\n\n%s\n' "OK!" (or, with full debugging output) # wineboot && printf '\n\n%s\n' "OK!" Actual Results: With wine 9.0, everything goes nuts and you'll have to kill the container (as ^C won't even work for me) or just wait for all resources to be exceeded and the processes killed. Expected Results: When using the quay.io/fedora/fedora:39 base (or rawhide with wine 8.19), it works fine, so I'd expect it continue to work fine and not forkbomb my system and enter an infinte loop.
The new (bad) output from wineboot looks like: cebc:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) cec0:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) cec8:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) cecc:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) ced4:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) cec4:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) ced8:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) ced0:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 75c8:err:msg:get_server_queue_handle Cannot get server thread queue cedc:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 6b10:err:msg:get_server_queue_handle Cannot get server thread queue cef4:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 75d0:err:msg:get_server_queue_handle Cannot get server thread queue 69d4:err:win:get_desktop_window failed to create desktop window cef0:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) cee4:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 69e4:err:win:get_desktop_window failed to create desktop window 69ec:err:win:get_desktop_window failed to create desktop window 69e0:err:win:get_desktop_window failed to create desktop window 69d8:err:win:get_desktop_window failed to create desktop window cf00:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 6b1c:err:msg:get_server_queue_handle Cannot get server thread queue e2b4:err:seh:install_bpf Unexpected status 0xffffffff, errno 9. e2ac:err:seh:install_bpf Unexpected status 0xffffffff, errno 9. e2b0:err:seh:install_bpf Unexpected status 0xffffffff, errno 9. e2b8:err:seh:install_bpf Unexpected status 0xffffffff, errno 9. e2a8:err:seh:install_bpf Unexpected status 0xffffffff, errno 9. 69dc:err:win:get_desktop_window failed to create desktop window 69e8:err:win:get_desktop_window failed to create desktop window which is output at extremely high speed (hundreds of megabytes of log output, if capturing) which didn't happen with the previous rawhide wine version 8.19. I've not yet tried to reproduce this outside of a container, as using command-line Windows applications in a container is my use case.
I should also add that wineboot, when run in the Fedora 39 container with Wine 8.19, will produce a lot of debugging output, mostly about not being able to open a window and to check the X server when run without WINEDEBUG=-all. These messages are completely normal, expected, and non-fatal when operating in a headless container. Probably not related, but during the "dnf install" phase, fontconfig throws an error during the installation when running a scriptlet, but does continue on: Installing : fontconfig-2.15.0-1.fc40.i686 643/676 Running scriptlet: fontconfig-2.15.0-1.fc40.i686 643/676 /usr/bin/fc-cache-32: error while loading shared libraries: libharfbuzz.so.0: cannot open shared obj ect file: No such file or directory The harfbuzz packages are always installed after the fontconfig packages, so I assume this is an error declaring the dependencies properly in some packages. However, I did try doing a "dnf reinstall fontconfig" so the scriptlet can run successfully, and then trying to run wineboot, but it still produces hundreds of megabytes of output and spawns thousands of explorer.exe processes, never completing, which is why I say it's likely not related to the problem.
I've also tried using both xvfb-run and x11vnc inside the container (which shouldn't be necessary, as it's always worked headless until now). Having X available didn't make any difference - wine 9 was still non-functional.
I can also confirm this seems to be a Fedora-specific problem and not a general Wine 9.0 problem (unless upstream WineHQ-staging repo has fixed this problem and the version Fedora is using has not). Using the (upstream) WineHQ F39 repo currently works fine with today's rawhide in a totally clean container: docker run --rm -it quay.io/fedora/fedora:rawhide dnf install -y harfbuzz.x86_64 harfbuzz.i686 dnf install -y 'dnf-command(config-manager)' dnf config-manager --add-repo https://dl.winehq.org/wine-builds/fedora/39/winehq.repo dnf install -y winehq-staging wineboot The WineHQ "wine --version" reports wine-9.0 (Staging)
I've tested the pending F39 updates-testing from https://bodhi.fedoraproject.org/updates/FEDORA-2024-b168a179c3 on a F39 container, and that works fine as well, so this is a Rawhide specific problem.
I am also getting the fork bomb effect on rawhide with 9.0-2, but not 9.0-1. I tried removing wine-smartcard since that was new with 9.0-2 (or at least it started getting pulled in by wine), but that didn't help with the fork bomb issue.
FEDORA-2024-3035848fad has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-3035848fad
FEDORA-2024-3035848fad has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
9.0-3 works for me. Thanks!