https://bugs.winehq.org/show_bug.cgi?id=41339
Bug ID: 41339 Summary: Minor regression: Wine loads with "/wine/dlls/ntdll/loader.c: loader_section" errors when creating a new prefix or running an application Product: Wine Version: 1.9.18 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: fjfrackiewicz@gmail.com Distribution: ---
I noticed that with Wine 1.9.18, whenever I either created a new prefix or ran an application I would receive the following errors in my terminal:
err:ntdll:RtlpWaitForCriticalSection section 0x7bcf4f84 "../../../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 001d, blocked by 001e, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7bcf4f84 "../../../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 001c, blocked by 001e, retrying (60 sec)
This issue was also brought up by Bruno Jesus in the wine-devel mailing list here: https://www.winehq.org/pipermail/wine-devel/2016-September/114672.html
Since I am not the only one experiencing this, I decided to run a regression test. According to the git bisect I have performed this issue first appears in wine-1.9.17-149-gd2b782f
The bad commit in question:
commit d2b782f4e4f0efa6e783031d57cf98789cdc4742 Author: Henri Verbeet hverbeet@codeweavers.com Date: Fri Aug 26 13:51:22 2016 +0200
ddraw: Rename "wineD3DVertexBuffer" to "wined3d_buffer".
Signed-off-by: Henri Verbeet hverbeet@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
:040000 040000 719fe9426a27661606b40339c96588fa09e3385e 07af319b9fd2e194b9a5990a0c09277d34ed42bb M dlls
https://bugs.winehq.org/show_bug.cgi?id=41339
fjfrackiewicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hverbeet@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=41339
fjfrackiewicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=41339
--- Comment #1 from fjfrackiewicz@gmail.com --- Added Bruno Jesus in CC as he was the one who originally reported the issue.
Please let me know if I can help by providing any additional info.
https://bugs.winehq.org/show_bug.cgi?id=41339
fjfrackiewicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |d2b782f4e4f0efa6e783031d57c | |f98789cdc4742
https://bugs.winehq.org/show_bug.cgi?id=41339
fjfrackiewicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=41339
fjfrackiewicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Hardware|x86 |x86-64
https://bugs.winehq.org/show_bug.cgi?id=41339
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=41339
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1|d2b782f4e4f0efa6e783031d57c | |f98789cdc4742 |
--- Comment #2 from Bruno Jesus 00cpxxx@gmail.com --- Thank you for your effort. The problem of debugging random failures is that sometimes we end with false commits. The commit that resulted from your test literally only renames variables so it can't be the offender.
https://bugs.winehq.org/show_bug.cgi?id=41339
--- Comment #3 from fjfrackiewicz@gmail.com --- (In reply to Bruno Jesus from comment #2)
Thank you for your effort. The problem of debugging random failures is that sometimes we end with false commits. The commit that resulted from your test literally only renames variables so it can't be the offender.
I see. Well, I do apologize for mislabelling the commit then.
The bisect never turned anything else up when testing with Wine 1.9.16 as "good" and Wine 1.9.18 as "bad"
Sorry for the hassle, please feel free to close the bug if required.
https://bugs.winehq.org/show_bug.cgi?id=41339
--- Comment #4 from Austin English austinenglish@gmail.com --- (In reply to fjfrackiewicz from comment #3)
(In reply to Bruno Jesus from comment #2)
Thank you for your effort. The problem of debugging random failures is that sometimes we end with false commits. The commit that resulted from your test literally only renames variables so it can't be the offender.
I see. Well, I do apologize for mislabelling the commit then.
The bisect never turned anything else up when testing with Wine 1.9.16 as "good" and Wine 1.9.18 as "bad"
Sorry for the hassle, please feel free to close the bug if required.
It's still a valid but, it just needs more careful testing. E.g., testing each commit several times, or putting the system under load first to see if if it's more reproducible that way.
https://bugs.winehq.org/show_bug.cgi?id=41339
--- Comment #5 from fjfrackiewicz@gmail.com --- (In reply to Austin English from comment #4)
(In reply to fjfrackiewicz from comment #3)
(In reply to Bruno Jesus from comment #2)
Thank you for your effort. The problem of debugging random failures is that sometimes we end with false commits. The commit that resulted from your test literally only renames variables so it can't be the offender.
I see. Well, I do apologize for mislabelling the commit then.
The bisect never turned anything else up when testing with Wine 1.9.16 as "good" and Wine 1.9.18 as "bad"
Sorry for the hassle, please feel free to close the bug if required.
It's still a valid but, it just needs more careful testing. E.g., testing each commit several times, or putting the system under load first to see if if it's more reproducible that way.
Right, I understand.
So far what I did was the following:
- create or update a prefix via "winecfg" several time per commit - install a program
I'll try again and see if I can't find an application that will put the system under load a bit more.
https://bugs.winehq.org/show_bug.cgi?id=41339
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #6 from winetest@luukku.com --- I remember seeing this with some wine version quite recently, but I haven't seen it anymore for a long time. I quess this is already fixed. Whatever caused it.
https://bugs.winehq.org/show_bug.cgi?id=41339
--- Comment #7 from fjfrackiewicz@gmail.com --- (In reply to winetest from comment #6)
I remember seeing this with some wine version quite recently, but I haven't seen it anymore for a long time. I quess this is already fixed. Whatever caused it.
Nah, it still happens from time to time, actually.
https://bugs.winehq.org/show_bug.cgi?id=41339
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #8 from Fabian Maurer dark.shadow4@web.de --- Is this still an issue?
https://bugs.winehq.org/show_bug.cgi?id=41339
--- Comment #9 from Nikolay Sivov bunglehead@gmail.com --- I think it is. Race of some sort.
https://bugs.winehq.org/show_bug.cgi?id=41339
Jarik y.salnikov65535@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |y.salnikov65535@gmail.com
--- Comment #10 from Jarik y.salnikov65535@gmail.com --- I have this bug always. How to reproduce: - set xinput1_3 to native in winecfg - get some apps that work with xinput, like this: http://pila.fr/wordpress/wp-content/uploads/SimpleXbox360ControllerTester.zi... - place dlls from https://github.com/kozec/dumbxinputemu in same directory as previous executable. - run it.
Bug tested on wine versions 2.11, 2.13, 3.0 and 3.1. Reproduce 100% of time on my system.
https://bugs.winehq.org/show_bug.cgi?id=41339
--- Comment #11 from Fabian Maurer dark.shadow4@web.de ---
Bug tested on wine versions 2.11, 2.13, 3.0 and 3.1. Reproduce 100% of time on my system.
Test with dumbxinputemu v0.3.2, it says "Fixed race condition (freezing at start) in Wine 3.0". This is a problem with the library, not wine itself.
https://bugs.winehq.org/show_bug.cgi?id=41339
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #12 from joaopa jeremielapuree@yahoo.fr --- I don't understand the bug. Does it still occur with wine-6.18?
https://bugs.winehq.org/show_bug.cgi?id=41339
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #13 from Rémi Bernon rbernon@codeweavers.com --- This has not been updated in several years and I believe the issue has been long solved. Please re-open with more details if it still happens.
https://bugs.winehq.org/show_bug.cgi?id=41339
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #14 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 8.0-rc3.