https://bugs.winehq.org/show_bug.cgi?id=52511
Bug ID: 52511 Summary: Race condition on exit of application Product: Wine Version: 7.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: winehq@jonass.user.lysator.liu.se Distribution: ---
Created attachment 71812 --> https://bugs.winehq.org/attachment.cgi?id=71812 Inital log. Shows threads waiting.
Version 7.0 seems to have introduced an race condition on exit of at least one application. https://appdb.winehq.org/objectManager.php?sClass=version&iId=6602
On exit I get these errors about two thread seeming to wait for each other. See attached log.
Repeating infinitely.
Tested both with 7.0 and wine-7.1-180-gadda27cdb82 on Xubuntu 20.04.3.
https://bugs.winehq.org/show_bug.cgi?id=52511
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Race condition on exit of |Hemekonomi hangs on exit |application |due to deadlock between | |loader_section and Win16 | |mutex Keywords| |win16
--- Comment #1 from Zebediah Figura z.figura12@gmail.com --- You say that this behaviour was "introduced" in 7.0; does that mean that it wasn't present before? Can you give a specific version that works?
Also, you say "race condition", does that mean the hang is not consistent?
https://bugs.winehq.org/show_bug.cgi?id=52511
--- Comment #2 from winehq@jonass.user.lysator.liu.se --- (In reply to Zebediah Figura from comment #1)
You say that this behaviour was "introduced" in 7.0; does that mean that it wasn't present before? Can you give a specific version that works?
Also, you say "race condition", does that mean the hang is not consistent?
Yes, I have not seen the problem before my system were updated to 7.0. Unfortunately I do not know exactly what version I had before, but I would say any and all one would get by following instructions on https://wiki.winehq.org/Ubuntu for Ubuntu version 18 or 20 for the last few years.
The hang is very consistent on my main system. But I tried to reproduce it with an virtual machine on the same hardware. At first I could not reproduce it at all. Then I begun testing the application more to write a test report. After a while I begun to get the same hang in the virtual machine also. Now it seems to be consistent on both machines.
https://bugs.winehq.org/show_bug.cgi?id=52511
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #3 from Fabian Maurer dark.shadow4@web.de --- Is there a free download to test with?
https://bugs.winehq.org/show_bug.cgi?id=52511
--- Comment #4 from Jonas winehq@jonass.user.lysator.liu.se --- (In reply to Fabian Maurer from comment #3)
Is there a free download to test with?
Unfortunatly no. It is probably abandoned since at least 15 years.
https://bugs.winehq.org/show_bug.cgi?id=52511
--- Comment #5 from Jonas winehq@jonass.user.lysator.liu.se --- (In reply to Zebediah Figura from comment #1)
You say that this behaviour was "introduced" in 7.0; does that mean that it wasn't present before? Can you give a specific version that works?
Checking log files I found that this seems to have happened with: dpkg.log.2:2022-01-21 17:51:21 upgrade wine-stable-i386:i386 6.0.2~bionic-1 7.0.0.0~bionic-1
I have not been able to found out how to set up that version again. But I set up a virtual machine and compiled 6.0.2 myself and it seems to confirm that the problem does not happen with 6.0.2.
https://bugs.winehq.org/show_bug.cgi?id=52511
--- Comment #6 from Jonas winehq@jonass.user.lysator.liu.se --- Also check with 7.4 from sudo apt install --install-recommends winehq-devel and the problem seems to still be there.
https://bugs.winehq.org/show_bug.cgi?id=52511
--- Comment #7 from Jonas winehq@jonass.user.lysator.liu.se --- Created attachment 72062 --> https://bugs.winehq.org/attachment.cgi?id=72062 How I compiled.
Tried to compiled some versions to see where the problem begins. 6.22 seems to have the problem. 6.21 seems to be fine.
However when compiling on xubuntu 21.10, neither 6.20 nor 6.21 were fine. Both had the problem. I am not sure why it differs.
https://bugs.winehq.org/show_bug.cgi?id=52511
--- Comment #8 from Jonas winehq@jonass.user.lysator.liu.se --- Created attachment 72638 --> https://bugs.winehq.org/attachment.cgi?id=72638 Comments from testing on 2022-06-23
Summary of tests I did today: - Seems like the problem is absent whenever the directory ~/.wine is not existing. - git bisect suggest the problem may be related to commit dfa11dc040f93aceec7009eeb3a57b95764c1c64 Oct 25 2021 - the problems is still there with a fresh compiled version
More in file test20220623.txt
https://bugs.winehq.org/show_bug.cgi?id=52511
--- Comment #9 from Jonas winehq@jonass.user.lysator.liu.se --- (In reply to Jonas from comment #8)
Created attachment 72638 [details]
Don't bother with the git bisect. I must have been sloppy. Trying to repeat and verify I get results all over.
https://bugs.winehq.org/show_bug.cgi?id=52511
--- Comment #10 from Jonas winehq@jonass.user.lysator.liu.se --- I have been trying to bisect more but I can't find anything conclusive. Testing done on Ubuntu 18.04.6 LTS i686.
My impressions are:
Up to about 6.10 is good.
6.11 to 6.18 can't be tested due to other bugs.
Somewhere around 6.19 the other bugs seems to be resolved but I can not say if there are any good version for this bug. I never find the same commit when I bisect.
In 6.21 the bug seems to be there.
https://bugs.winehq.org/show_bug.cgi?id=52511
Jonas winehq@jonass.user.lysator.liu.se changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://archive.org/details | |/hemekonomi-306
--- Comment #11 from Jonas winehq@jonass.user.lysator.liu.se --- I found the software at the Archive.org, download the Hemekonomi306.tgz, unpack and run like "wine Hemeko.exe".
https://bugs.winehq.org/show_bug.cgi?id=52511
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com Keywords| |download, regression
https://bugs.winehq.org/show_bug.cgi?id=52511
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |374ad339048e73269d9590ed343 | |8e959179fee09 CC| |gyebro69@gmail.com, | |piotr@codeweavers.com
--- Comment #12 from Béla Gyebrószki gyebro69@gmail.com --- @Jonas: Does running the app with `taskset -c 0` make a difference?
I can reproduce the problem and performed the regression test. The problem appeared in Wine-6.20 with this commit:
commit 374ad339048e73269d9590ed3438e959179fee09 user32: Set IMM active context on focus change.
Still present in Wine-7.18.
https://bugs.winehq.org/show_bug.cgi?id=52511
--- Comment #13 from Jonas winehq@jonass.user.lysator.liu.se --- taskset seems to work sometimes, but only sometimes.
https://bugs.winehq.org/show_bug.cgi?id=52511
--- Comment #14 from Jonas winehq@jonass.user.lysator.liu.se --- Still present in Wine-7.21.
https://bugs.winehq.org/show_bug.cgi?id=52511
--- Comment #15 from Fabian Maurer dark.shadow4@web.de --- Created attachment 73528 --> https://bugs.winehq.org/attachment.cgi?id=73528 Patch so fix the issue
Code flow is like follows:
- DOSVM_Exit -> RtlExitUserThread -> LdrShutdownThread - acquire loader lock - send DLL_THREAD_DETACH to imm32 - - calls DestroyWindow on its window - - WM_DESTROY is handled asynchonously! - send DLL_THREAD_DETACH to krnl386.exe - - TASK_ExitTask - - try get win16 lock, is blocked by ime32
meanwhile, at ime32
- handles WM_DESTROY - already have win16 lock from user32 - __wine_ime_wnd_proc (WM_DESTROY) -> imm_couninit_thread -> CoRevokeInitializeSpy - LdrGetProcedureAddress (want CoRevokeInitializeSpy) - try get loader_lock, is blocked
Solution is to wait in ime32 DllMain until the cleanup as happened, aka CoRevokeInitializeSpy has finished.
Attached a patch that should fix the issue, could you please confirm this works for you as well?
https://bugs.winehq.org/show_bug.cgi?id=52511
--- Comment #16 from Jonas winehq@jonass.user.lysator.liu.se --- (In reply to Fabian Maurer from comment #15)
Yes, the patch seems to resolve the issue. Thank you very much!
Will you submit it for future releases?
https://bugs.winehq.org/show_bug.cgi?id=52511
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #17 from Fabian Maurer dark.shadow4@web.de --- I'll try, yes. MR is at https://gitlab.winehq.org/wine/wine/-/merge_requests/1456
https://bugs.winehq.org/show_bug.cgi?id=52511
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |5be2a01ce69c19fa89c0dea0165 | |ffe185c69e326
--- Comment #18 from Fabian Maurer dark.shadow4@web.de --- Fixed by https://gitlab.winehq.org/wine/wine/-/commit/5be2a01ce69c19fa89c0dea0165ffe1...
https://bugs.winehq.org/show_bug.cgi?id=52511
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #19 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 7.22.
https://bugs.winehq.org/show_bug.cgi?id=52511
--- Comment #20 from Jonas winehq@jonass.user.lysator.liu.se --- I can confirm, this problem is solved in 7.22.
Thanks to Fabian Maurer for submitting a fix. Also thanks to Zeb Figura and Béla Gyebrószki for helping with this problem report.