http://bugs.winehq.org/show_bug.cgi?id=31882
Bug #: 31882 Summary: arial32.exe randomly crash or deadlock while installing Product: Wine Version: 1.5.14 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: fracting@gmail.com Classification: Unclassified
Created attachment 41968 --> http://bugs.winehq.org/attachment.cgi?id=41968 Log: arai32 crash while installing
wine-1.5.14-142-g730479e
$ sha1sum arial32.exe 6d75f8436f39ab2da5c31ce651b7443b4ad2916e arial32.exe
Steps to reproduce: $ winetricks -q corefont
Or $ wine arial32.exe /q
How reproducible: crash > 1/10 deadlock > 1/10
When deadlock, output is: err:ntdll:RtlpWaitForCriticalSection section 0x15d60c "bitblt.c: surface" wait timed out in thread 0009, blocked by 0024, retrying (60 sec)
When crashing, backtrace is:
Backtrace: =>0 0xb757d08d __pthread_cond_signal+0xd() in libpthread.so.0 (0x0054e4d4) 1 0x7e4c4758 in libxcb.so.1 (+0x8757) (0x0054e4d4) 2 0x7e4c363e in libxcb.so.1 (+0x763d) (0x0054e4d4) 3 0x7e4c36c1 xcb_writev+0x70() in libxcb.so.1 (0x7d3d856c) 4 0x7e5330d0 _XSend+0x15f() in libx11.so.6 (0x0054e558) 5 0x7e5334fa _XFlush+0x39() in libx11.so.6 (0x0054e5f8) 6 0x7e512fc1 XFlush+0x30() in libx11.so.6 (0x0054e5f8) 7 0x7e681ecc create_x11_physdev+0xe1(drawable=0xae) [/home/fracting/wine-git/dlls/winex11.drv/init.c:116] in winex11 (0x0054e5f8) 8 0x7e681ef6 X11DRV_CreateDC+0x1f(pdev=0x15ce38, driver="DISPLAY", device=0x0(nil), output=0x0(nil), initData=(nil)) [/home/fracting/wine-git/dlls/winex11.drv/init.c:126] in winex11 (0x0054e638) 9 0x7eab3ddf CreateDCW+0x251(driver="DISPLAY", device=0x0(nil), output=0x0(nil), initData=(nil)) [/home/fracting/wine-git/dlls/gdi32/dc.c:594] in gdi32 (0x0054e918) 10 0x7e9b3af4 alloc_dce+0x76() [/home/fracting/wine-git/dlls/user32/painting.c:232] in user32 (0x0054e948) 11 0x7e9b59e2 GetDCEx+0x34d(hwnd=0x30028, hrgnClip=(nil), flags=0x10000) [/home/fracting/wine-git/dlls/user32/painting.c:1033] in user32 (0x0054e9c8)
http://bugs.winehq.org/show_bug.cgi?id=31882
Qian Hong fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://downloads.sourceforg | |e.net/project/corefonts/the | |%20fonts/final/arial32.exe
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #1 from Rico kgbricola@web.de 2012-10-04 07:49:55 CDT --- Looks a bit similar to 31406 ... through it may be an other bug ...
Is this a regression?
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #2 from Qian Hong fracting@gmail.com 2012-10-04 07:53:47 CDT --- (In reply to comment #1)
Looks a bit similar to 31406 ... through it may be an other bug ...
Is this a regression?
I believe it is a regression, but I have no time to test and bisect right now :(
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #3 from Qian Hong fracting@gmail.com 2012-10-04 09:52:51 CDT --- The installer of Mahaa demo also hits by deadlock with err:ntdll:RtlpWaitForCriticalSection section 0x7ebeb908 "win.c: surfaces_section" wait timed out in thread 0028, blocked by 0048, retrying (60 sec)
Mahaa demo download page: http://compactiongames.about.com/od/demos/p/mohaa.htm
http://bugs.winehq.org/show_bug.cgi?id=31882
GyB gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
--- Comment #4 from GyB gyebro69@gmail.com 2012-10-04 11:43:43 CDT --- I believe the commit that made this bug appear is 5a9de7a4989dcf08914b5efd3152248a70be4548 is the first bad commit commit 5a9de7a4989dcf08914b5efd3152248a70be4548 Author: Alexandre Julliard julliard@winehq.org Date: Wed Oct 3 15:26:08 2012 +0200
winex11: Use the XShm extension to copy window surfaces.
:040000 040000 3413532a1e603b28149cf2cddc2fe06fd7dbb3a2 2da7fe865540b91e09b2b96f03d43455551bf9ef M dlls
I came across this bug yesterday, when submitting bug #31879. Aquanox demo may hang during the installation (during the file copying stage). Just like bug #31406, it is not fully reproducible: the installer may hang 1..2..n times in a row, then it runs without freezing 1..2..n times. I receive the same terminal output (and backtrace) as posted in comment #0.
Fedora 17 X.Org X Server 1.12.3 libxcb-1.8.1-1.fc17.i686
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2012-10-04 11:46:26 CDT --- Yes, looks like another libxcb threading bug.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #6 from Qian Hong fracting@gmail.com 2012-10-04 12:00:32 CDT --- (In reply to comment #5)
Yes, looks like another libxcb threading bug.
Its a bit difficult for me to write a libxcb-only test case to demo this bug, anyone have enough love to report this bug to the libxcb folks? ;-)
http://bugs.winehq.org/show_bug.cgi?id=31882
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Regression SHA1| |5a9de7a4989dcf08914b5efd315 | |2248a70be4548
http://bugs.winehq.org/show_bug.cgi?id=31882
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |31888
http://bugs.winehq.org/show_bug.cgi?id=31882
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover@mines.edu
--- Comment #7 from Erich Hoover ehoover@mines.edu 2012-10-04 23:21:37 CDT --- (In reply to comment #6)
(In reply to comment #5)
Yes, looks like another libxcb threading bug.
Its a bit difficult for me to write a libxcb-only test case to demo this bug, anyone have enough love to report this bug to the libxcb folks? ;-)
What version of libxcb are you using? That particular backtrace looks like an issue from libxcb 1.7 that was resolved in 1.8.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #8 from Qian Hong fracting@gmail.com 2012-10-05 00:32:38 CDT --- (In reply to comment #7)
What version of libxcb are you using? That particular backtrace looks like an issue from libxcb 1.7 that was resolved in 1.8.
I'm using libxcb 1.7-3 from Ubuntu 10.10 repository. Due to Bug comment #4 GyB is using libxcb-1.8.1-1.fc17.i686 and get the same backtrace.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #9 from Erich Hoover ehoover@mines.edu 2012-10-05 07:09:49 CDT --- (In reply to comment #8)
... I'm using libxcb 1.7-3 from Ubuntu 10.10 repository. Due to Bug comment #4 GyB is using libxcb-1.8.1-1.fc17.i686 and get the same backtrace.
You may want to download libxcb's git and try the most up-to-date version that includes the fix for Bug #31406. The backtrace is very similar, though not identical, for that issue.
GyB: could you give that a try as well?
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #10 from GyB gyebro69@gmail.com 2012-10-05 08:33:03 CDT --- Created attachment 41977 --> http://bugs.winehq.org/attachment.cgi?id=41977 backtrace (Aquanox demo installer deadlock)
My bad...the backtrace on my system actually is not quite the same as the one in comment #0. I have to wait until libxcb-1.9 hits the updates-testing repo on Fedora, because I'm not familiar with compiling Xserver on my own.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #11 from Erich Hoover ehoover@mines.edu 2012-10-05 09:11:00 CDT --- (In reply to comment #10)
Created attachment 41977 [details] backtrace (Aquanox demo installer deadlock)
My bad...the backtrace on my system actually is not quite the same as the one in comment #0. I have to wait until libxcb-1.9 hits the updates-testing repo on Fedora, because I'm not familiar with compiling Xserver on my own.
Yup, that's the backtrace for Bug #31406. You don't need to compile the entire Xserver to compile libxcb, you can just download libxcb from their git repository and go through the traditional "./configure && make && sudo make install" routine. After that you'll just need to use LD_LIBRARY_PATH="/usr/local/lib" or it will continue to use the system library.
Anyway, this bug _should_ be resolvable by upgrading to libxcb 1.8 or newer.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #12 from GyB gyebro69@gmail.com 2012-10-05 09:55:27 CDT --- I managed to compile and install libxcb-1.9. I added to the configure script: --enable-selinux --enable-xinput --enable-xkb, because they were disabled by default, no idea if that matters. So far so good..the freezing issue no longer occurs when installing Aquanox demo. I keep testing Wine with libxcb-1.9 to see if other games that I know that have bug #31406 are working fine.
http://bugs.winehq.org/show_bug.cgi?id=31882
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |focht@gmx.net Component|-unknown |winex11.drv Summary|arial32.exe randomly crash |Many multithreaded gui apps |or deadlock while |randomly deadlock in |installing |winex11 driver surface | |section (arial32.exe, | |Aquanox, Mahaa demo, Total | |Commander) Ever Confirmed|0 |1
--- Comment #13 from Anastasius Focht focht@gmx.net 2012-10-06 04:44:17 CDT --- Hello Erich,
--- quote --- Anyway, this bug _should_ be resolvable by upgrading to libxcb 1.8 or newer. --- quote ---
The freshly released libxcb 1.9 (libxcb-1.9.tar.bz2, 05-Oct-2012 05:58, 379K) is needed which includes the multithreading patch. Without the upgrade any multithreaded gui app is prone to deadlocks. I encountered this bug in several installers (winetricks recipes) and other apps I regularly use.
The problem is with the older distros where libxcb may stay as it is for a long time or forever if no upgrade path/EOL. You will get a ton of bug reports because of this issue if these distros package wine-1.5.15+ or people build Wine on their own there. They need to revert 5a9de7a4989dcf08914b5efd3152248a70be4548 to avoid libxcb and dependencies upgrade path.
BTW cherry picking the multithreading patch didn't help for older libxcb 1.7. The problem was still present hence I did a full upgrade to 1.9. This is not something the average user does. It involves upgrading/rebuilding package and its dependencies. For my slightly older Fedora 16 which has libxcb 1.7 it worked out, though I had to upgrade/rebuild xcb-proto too.
Although the root cause seems to be the same, the libxcb bug is exposed through a different code path/module in Wine. If you mark this bug a dupe of bug 31406 you should make a better summary there because it affects a _wide_ range of apps. Another option could be to close this upstream too and keep it separate to collect all dupes containing winex11 surface deadlocks here.
http://cgit.freedesktop.org/xcb/libxcb/commit/?id=23911a707b8845bff52cd7853f...
Regards
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #14 from Erich Hoover ehoover@mines.edu 2012-10-08 11:16:11 CDT --- (In reply to comment #13)
... Although the root cause seems to be the same, the libxcb bug is exposed through a different code path/module in Wine. If you mark this bug a dupe of bug 31406 you should make a better summary there because it affects a _wide_ range of apps. Another option could be to close this upstream too and keep it separate to collect all dupes containing winex11 surface deadlocks here. ...
This particular bug is actually a different problem in XCB (https://bugs.freedesktop.org/show_bug.cgi?id=40372 , http://cgit.freedesktop.org/xcb/libxcb/commit/?id=5ceeaaa4294201b3f613c07f9e...). I also ran into this bug since I started with an old libxcb. As a result I discovered that it's easy to upgrade libxcb independent of the rest of X11, so we could try and convince the distros to push libxcb 1.9 to older releases. I'm not sure what the best option is to help people out wrt. them running into issues with older releases, I'm sure you have much more experience dealing with that then I do.
http://bugs.winehq.org/show_bug.cgi?id=31882
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |UPSTREAM
--- Comment #15 from Alexandre Julliard julliard@winehq.org 2012-10-08 16:06:40 CDT --- Upstream bug.
http://bugs.winehq.org/show_bug.cgi?id=31882
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kennybobs@o2.co.uk
--- Comment #16 from Ken Sharp kennybobs@o2.co.uk 2012-10-09 19:26:27 CDT --- Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/1064772 Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689269
This breaks "winetricks comctl32".
http://bugs.winehq.org/show_bug.cgi?id=31882
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nob.dir.info@gmail.com
--- Comment #17 from Alexandre Julliard julliard@winehq.org 2012-10-10 11:18:32 CDT --- *** Bug 31935 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=31882
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ajsb@vfemail.net
--- Comment #18 from Alexandre Julliard julliard@winehq.org 2012-10-13 17:34:28 CDT --- *** Bug 31959 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=31882
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Manuel.Bihl@gmx.de
--- Comment #19 from Alexandre Julliard julliard@winehq.org 2012-10-13 17:35:58 CDT --- *** Bug 31960 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=31882
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrewresch@gmail.com
--- Comment #20 from Alexandre Julliard julliard@winehq.org 2012-10-14 03:00:30 CDT --- *** Bug 31911 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=31882
GyB gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sniper290@inbox.ru
--- Comment #21 from GyB gyebro69@gmail.com 2012-10-14 08:40:22 CDT --- *** Bug 31969 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=31882
nob.dir.info@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|nob.dir.info@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=31882
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |john015@libero.it
--- Comment #22 from Bruno Jesus 00cpxxx@gmail.com 2012-10-14 15:19:16 CDT --- *** Bug 31972 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #23 from AJSB ajsb@vfemail.net 2012-10-15 03:07:36 CDT --- Updating libxcb (and xcb-proto i my distro because it was outdated for libxcb) solved almost all problems except comctl32 that will fail using winetricks.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #24 from AJSB ajsb@vfemail.net 2012-10-15 03:26:13 CDT --- Well, after all situation with comctl32 isn't that serious...
winetricks comctl32
...will fail for sure, but it seems that you just need to reissue....
winetricks comctl32
....again, and this time the installer will go all the way w/o errors :D
Can anyone confirm that this is a correct workaround for comctl32 ?
If so, maybe a winetricks code revision to "implement" this workaround ?
http://bugs.winehq.org/show_bug.cgi?id=31882
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bonnassem@hotmail.com
--- Comment #25 from Alexandre Julliard julliard@winehq.org 2012-10-15 12:47:37 CDT --- *** Bug 31980 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=31882
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |r3pek@r3pek.org
--- Comment #26 from Alexandre Julliard julliard@winehq.org 2012-10-19 15:45:13 CDT --- *** Bug 32012 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #27 from Manu Manuel.Bihl@gmx.de 2012-10-20 01:50:47 CDT --- (In reply to comment #24)
Well, after all situation with comctl32 isn't that serious...
winetricks comctl32
...will fail for sure, but it seems that you just need to reissue....
winetricks comctl32
....again, and this time the installer will go all the way w/o errors :D
Can anyone confirm that this is a correct workaround for comctl32 ?
If so, maybe a winetricks code revision to "implement" this workaround ?
This is NOT the correct workaround. I've experienced this with "all" apps that got this Bug for me. If you rerun them multiple times they will work without the deadlock. I think this is the case for comctl32 too.
http://bugs.winehq.org/show_bug.cgi?id=31882
Marcus Meissner marcus@jet.franken.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marcus@jet.franken.de
http://bugs.winehq.org/show_bug.cgi?id=31882
Josh DuBois duboisj@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |duboisj@codeweavers.com
--- Comment #28 from Josh DuBois duboisj@codeweavers.com 2012-10-22 07:48:39 CDT --- (In reply to comment #0)
Steps to reproduce: $ winetricks -q corefont
Or $ wine arial32.exe /q
How reproducible: crash > 1/10 deadlock > 1/10
Qian:
Does it look to you like using libxcb 1.9 fixes the corefonts issue? It still seems broken, here. Or, AJSB, you say updating libxcb solves "most" problems. Do you recall whether it reliably fixes corefonts for you? (E.g., running as Qian says 10 times, do you never get a crash)?
Of course, maybe I'm seeing a different bug ...
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #29 from Qian Hong fracting@gmail.com 2012-10-22 08:34:31 CDT --- (In reply to comment #28)
Sorry for no response to Erich.
I build libxcb 1.9 and make sure wine uses the new libxcb: $ ldd /usr/local/lib/wine/winex11.drv.so | grep libxcb libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0xb726d000)
Then I use `winetricks -q corefonts` to install corefont, and get the below deadlock: --- err:ntdll:RtlpWaitForCriticalSection section 0x7ea23948 "win.c: surfaces_section" wait timed out in thread 002c, blocked by 002e, retrying (60 sec) ---
and another deadlock: --- err:ntdll:RtlpWaitForCriticalSection section 0x13dba4 "bitblt.c: surface" wait timed out in thread 0037, blocked by 0000, retrying (60 sec) ---
I got the first deadlock one time in ten times, the second deadlock three time in ten times, I no longer see crashing now.
wine-1.5.15-204-g673617e
http://bugs.winehq.org/show_bug.cgi?id=31882
Josh DuBois duboisj@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|UPSTREAM |
--- Comment #30 from Josh DuBois duboisj@codeweavers.com 2012-10-22 08:59:21 CDT --- Sounds like two of us still see the problem with corefonts, even with libxcb 1.9. I'm reopening, which I hope isn't too hasty. (If its the wrong thing to do I"m happy to file a different bug, etc.)
http://bugs.winehq.org/show_bug.cgi?id=31882
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |UPSTREAM
--- Comment #31 from Alexandre Julliard julliard@winehq.org 2012-10-22 09:13:04 CDT --- You would want to reopen the upstream bug then, it's still not a Wine bug.
http://bugs.winehq.org/show_bug.cgi?id=31882
Guillaume gufide_g@yahoo.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gufide_g@yahoo.ca
--- Comment #32 from Guillaume gufide_g@yahoo.ca 2012-10-22 15:40:15 CDT --- *** Bug 31974 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=31882
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |moncure@umich.edu
--- Comment #33 from Austin English austinenglish@gmail.com 2012-10-22 20:29:56 CDT --- *** Bug 32033 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=31882
puthre@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |puthre@gmail.com
--- Comment #34 from puthre@gmail.com 2012-10-23 05:44:11 CDT --- I get 'err:ntdll:RtlpWaitForCriticalSection section 0x10c95f0c "bitblt.c: surface" wait timed out in thread 0009, blocked by 0040, retrying (60 sec)' every few minutes in Adobe Fireworks CS3 with wine-1.5.15, in Ubuntu 12.04.1 LTS. Fireworks it's unusable right now.
http://bugs.winehq.org/show_bug.cgi?id=31882
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |orbanbalint@gmail.com
--- Comment #35 from Alexandre Julliard julliard@winehq.org 2012-10-23 10:08:31 CDT --- *** Bug 32045 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #36 from Erich Hoover ehoover@mines.edu 2012-10-23 10:26:55 CDT --- (In reply to comment #34)
I get 'err:ntdll:RtlpWaitForCriticalSection section 0x10c95f0c "bitblt.c: surface" wait timed out in thread 0009, blocked by 0040, retrying (60 sec)' every few minutes in Adobe Fireworks CS3 with wine-1.5.15, in Ubuntu 12.04.1 LTS. Fireworks it's unusable right now.
Please enable the precise-proposed repository and upgrade your libxcb package.
http://bugs.winehq.org/show_bug.cgi?id=31882
René Kjellerup rk.katana.steel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rk.katana.steel@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=31882
Jacob Litewski hackhalotwo@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hackhalotwo@gmail.com
--- Comment #37 from Jacob Litewski hackhalotwo@gmail.com 2012-10-23 19:56:23 CDT --- I'm getting a similar error with gmod 13 beta on a fully updated Arch install (as of today). libxcb version is 1.9-1, wine is 1.5.15
"err:ntdll:RtlpWaitForCriticalSection section 0x694326c "?" wait timed out in thread 0096, blocked by 0000, retrying (60 sec)" repeats every minute after the level is about 90% loaded.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #38 from René Kjellerup rk.katana.steel@gmail.com 2012-10-23 21:09:13 CDT --- I get this too trying to install Magic the Gathering Online III
in Gentoo Linux with wine-1.5.15-r1
err:ntdll:RtlpWaitForCriticalSection section 0x7eaf5960 "/var/tmp/portage/app-emulation/wine-1.5.15-r1/work/wine-1.5.15/dlls/user32/win.c: surfaces_section" wait timed out in thread 0023, blocked by 0009, retrying (60 sec)
http://bugs.winehq.org/show_bug.cgi?id=31882
Anton Vorobyov phoenix@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |phoenix@mail.ru
--- Comment #39 from Anton Vorobyov phoenix@mail.ru 2012-10-24 01:59:53 CDT --- One of the users in dota 2 discussion thread mentioned that he fixed "remaining" hangs (he worked around other group of hangs before) by setting strict draw ordering to enabled. These hangs, according to his description, sound very similar to the ones discussed here.
Is it eligible workaround or should have no effect on hangs at all?
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #40 from Jacob Litewski hackhalotwo@gmail.com 2012-10-24 09:14:35 CDT --- ivee on #winehq suggested setting the "nosmp" kernel flag may help. I currently cannot try this because it takes to long for the kernel to initiate laptop-mode, which causes my computer to thermal shutdown due to the fan not running.
I'm going to try to see if other Source Engine games trigger the same issue.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #41 from Erich Hoover ehoover@mines.edu 2012-10-24 09:15:27 CDT --- (In reply to comment #37)
I'm getting a similar error with gmod 13 beta on a fully updated Arch install (as of today). libxcb version is 1.9-1, wine is 1.5.15 ...
(In reply to comment #38)
I get this too trying to install Magic the Gathering Online III in Gentoo Linux with wine-1.5.15-r1 ...
Did you make sure that your 32-bit libxcb is updated?
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #42 from Alexandre Julliard julliard@winehq.org 2012-10-24 11:48:57 CDT --- There's still something broken in libxcb 1.9. Here's the backtrace of a deadlock from running arial32.exe:
#0 0xf77e1425 in __kernel_vsyscall () #1 0xf7643f02 in __lll_lock_wait () from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 #2 0xf7641a77 in pthread_cond_signal@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 #3 0x7e741fb5 in _xcb_in_wake_up_next_reader (c=0x7da05060) at xcb_in.c:623 #4 0x7e740a00 in _xcb_out_send (c=0x7da05060, vector=0x0, count=0) at xcb_out.c:352 #5 0x7e7407c9 in xcb_writev (c=0x7da05060, vector=0x53e5b8, count=3, requests=6) at xcb_out.c:297 #6 0x7e798440 in _XSend () from /usr/lib32/libX11.so.6 #7 0x7e79886a in _XFlush () from /usr/lib32/libX11.so.6 #8 0x7e778ef1 in XFlush () from /usr/lib32/libX11.so.6 #9 0x7e8eca8b in create_x11_physdev (drawable=346) at init.c:116
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #43 from Erich Hoover ehoover@mines.edu 2012-10-24 12:04:06 CDT --- (In reply to comment #42)
There's still something broken in libxcb 1.9. Here's the backtrace of a deadlock from running arial32.exe:
#0 0xf77e1425 in __kernel_vsyscall () #1 0xf7643f02 in __lll_lock_wait () from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 #2 0xf7641a77 in pthread_cond_signal@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 #3 0x7e741fb5 in _xcb_in_wake_up_next_reader (c=0x7da05060) at xcb_in.c:623 #4 0x7e740a00 in _xcb_out_send (c=0x7da05060, vector=0x0, count=0) at xcb_out.c:352 #5 0x7e7407c9 in xcb_writev (c=0x7da05060, vector=0x53e5b8, count=3, requests=6) at xcb_out.c:297 #6 0x7e798440 in _XSend () from /usr/lib32/libX11.so.6 #7 0x7e79886a in _XFlush () from /usr/lib32/libX11.so.6 #8 0x7e778ef1 in XFlush () from /usr/lib32/libX11.so.6 #9 0x7e8eca8b in create_x11_physdev (drawable=346) at init.c:116
Thanks so much, that's exactly what I need to try and look into this. So far I've been unable to reproduce the arial32 problem :/
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #44 from René Kjellerup rk.katana.steel@gmail.com 2012-10-24 12:15:50 CDT --- (In reply to comment #41)
(In reply to comment #38)
I get this too trying to install Magic the Gathering Online III in Gentoo Linux with wine-1.5.15-r1 ...
Did you make sure that your 32-bit libxcb is updated?
I've just updated the 32-bit binaries to the latest in the repo emul-linux-x86-xlibs-20120520 along with the others needed too and I still get the deadlock
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #45 from Jacob Litewski hackhalotwo@gmail.com 2012-10-24 12:49:03 CDT --- (In reply to comment #41)
(In reply to comment #37)
I'm getting a similar error with gmod 13 beta on a fully updated Arch install (as of today). libxcb version is 1.9-1, wine is 1.5.15 ...
(In reply to comment #38)
I get this too trying to install Magic the Gathering Online III in Gentoo Linux with wine-1.5.15-r1 ...
Did you make sure that your 32-bit libxcb is updated?
Yea, it updated with libxcb. https://www.archlinux.org/packages/?sort=&q=libxcb&maintainer=&l... is what's in the repos now.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #46 from Josh DuBois duboisj@codeweavers.com 2012-10-25 16:15:52 CDT --- (In reply to comment #43)
Thanks so much, that's exactly what I need to try and look into this. So far I've been unable to reproduce the arial32 problem :/
Hi Erich,
Do you get core fonts installing correctly on a regular basis with libxcb1.9 where you are? We see failure here quite regularly. (Not 100% consistent, but certainly in a loop of 10 installs, several will fail.)
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #47 from Anton Vorobyov phoenix@mail.ru 2012-10-26 03:36:06 CDT --- Today debian testing saw following update:
libxcb (1.8.1-2) unstable; urgency=low
- Cherry-pick from upstream 1.9: Fix a multi-thread deadlock. This fixes a deadlock which was seen in-the-wild with wine. It could happen that two threads tried to read from the socket at the same time and one of the thread got stuck inside of poll()/select(). The fix works by making sure that the writing thread doesn't steal the reading thread's reply. Closes: #689269.
-- Julien Cristau jcristau@debian.org Mon, 15 Oct 2012 21:13:33 +0200
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #48 from Henri Verbeet hverbeet@gmail.com 2012-10-27 00:51:16 CDT --- I looked at this a bit, and what seems to be happening is that the application ends up calling TerminateThread() -> ... -> pthread_exit() while the thread that gets terminated is inside x11drv_surface_flush() -> XSync() -> ... -> wait_for_reply() -> _xcb_conn_wait(). Then, when a different thread accesses the xcb reader list in _xcb_in_wake_up_next_reader(), the reader entry for the thread that was terminated now points to freed memory, which explains the pthread_cond_signal() call in there either blocking or crashing. There seems to be a somewhat similar issue if a thread gets terminated while holding the "c->iolock" mutex inside libxcb.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #49 from Henri Verbeet hverbeet@gmail.com 2012-10-27 01:17:47 CDT --- Created attachment 42273 --> http://bugs.winehq.org/attachment.cgi?id=42273 patch
Actually, the attached patch seems fairly good at avoiding the issue. I'm not quite familiar enough with all the code to judge how proper this is, but the basic idea is to avoid making X11 calls until message handler has had a chance to finish.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #50 from Qian Hong fracting@gmail.com 2012-10-27 05:02:24 CDT --- (In reply to comment #49)
Created attachment 42273 [details] patch
Thanks for the work! This patch works for me, I ran aria32 in a 1000-time-loops, no deadlock or crashing found.
Regards :)
http://bugs.winehq.org/show_bug.cgi?id=31882
Maxim Velesyuk loz.accs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |loz.accs@gmail.com
--- Comment #51 from Maxim Velesyuk loz.accs@gmail.com 2012-10-28 07:33:15 CDT --- I still got problems with Dota 2, bug #31911 was closed as duplicating this, but on wine-1.5.16, libxcb-1.8.1 (with multithread deadlock patch) dota randomly crashes with message:
err:d3d_surface:surface_blt_fbo >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glBlitFramebuffer() @ /var/tmp/portage/app-emulation/wine-1.5.16/work/wine-1.5.16/dlls/wined3d/surface.c / 1265
If this bug fixed upstream, why does this happen?
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #52 from Josh DuBois duboisj@codeweavers.com 2012-10-28 13:23:42 CDT --- I only ran it 200 times, but it resolved the problem with arial32.exe on my Ubnutu 11.10 VM, also.
(In reply to comment #49)
Created attachment 42273 [details] patch
Actually, the attached patch seems fairly good at avoiding the issue. I'm not quite familiar enough with all the code to judge how proper this is, but the basic idea is to avoid making X11 calls until message handler has had a chance to finish.
http://bugs.winehq.org/show_bug.cgi?id=31882
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@codeweavers.com
--- Comment #53 from Ken Thomases ken@codeweavers.com 2012-10-28 14:22:25 CDT --- (In reply to comment #49)
Created attachment 42273 [details] patch
Actually, the attached patch seems fairly good at avoiding the issue. I'm not quite familiar enough with all the code to judge how proper this is, but the basic idea is to avoid making X11 calls until message handler has had a chance to finish.
The problem is that you really do want to flush the surface before waiting on events. You can't have unflushed drawing pending for indefinite periods, especially if the the user is supposed to be reacting to whatever is supposed to have been drawn.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #54 from Ken Thomases ken@codeweavers.com 2012-10-28 14:57:35 CDT --- (In reply to comment #48)
I looked at this a bit, and what seems to be happening is that the application ends up calling TerminateThread() -> ... -> pthread_exit() while the thread that gets terminated is inside x11drv_surface_flush() -> XSync() -> ... -> wait_for_reply() -> _xcb_conn_wait(). Then, when a different thread accesses the xcb reader list in _xcb_in_wake_up_next_reader(), the reader entry for the thread that was terminated now points to freed memory, which explains the pthread_cond_signal() call in there either blocking or crashing. There seems to be a somewhat similar issue if a thread gets terminated while holding the "c->iolock" mutex inside libxcb.
Hmm. pthread_exit() is a means for a thread to terminate itself, not some arbitrary thread. So, how can a thread call that if it's blocked inside of libX11 or libxcb? The only mechanism I can see is from the wineserver's kill_thread() sending SIGQUIT, causing (inside of ntdll) quit_handler() -> abort_thread() -> terminate_thread() -> pthread_exit().
Is that what's happening?
I don't blame libxcb for failing to properly handle the case where a thread is unceremoniously terminated while within it. It seems the Wine bug is that it needs to protect the libraries it uses -- at least libX11/libxcb -- from that sort of abrupt termination, I guess using signal handlers. (Although such protection may be both impractical and would prevent proper termination of threads while they're blocked in library calls.)
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #55 from Josh DuBois duboisj@codeweavers.com 2012-10-28 15:12:34 CDT --- (In reply to comment #51)
I still got problems with Dota 2, bug #31911 was closed as duplicating this, but on wine-1.5.16, libxcb-1.8.1 (with multithread deadlock patch) dota randomly crashes with message:
err:d3d_surface:surface_blt_fbo >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glBlitFramebuffer() @ /var/tmp/portage/app-emulation/wine-1.5.16/work/wine-1.5.16/dlls/wined3d/surface.c / 1265
If this bug fixed upstream, why does this happen?
I am by no means qualified to tell whether your DOTA crash is related to this bug, but because others think it is, I am curious to know when / whether it's fixed ;)
I think what is happening is that a separate bug is in the process of being unearthed, and that changes to wine may be forthcoming which may address your issue. (See Henri's post above yours, and Ken's below). Essentially, there were upstream bugs which were fixed in libxcb, but now there appear to be problems in wine itself which cause similar symptoms.
Testing whether this is so may require applying a patch to wine once fixes are available (or, alternately, waiting for a release of wine which includes fixes).
So, if you are willing, I would encourage you to wait a bit for more fixes ... if you need help applying patches, feel free to write me and I will try to walk you through it.
Sorry if I'm telling you things you already know ... I don't recognize all the users here ... just trying to encourage any user with this kind of bug to re-test when it's believed truly fixed, and willing to offer help with that if it's needed.
Cheers.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #56 from Ken Thomases ken@codeweavers.com 2012-10-28 15:20:33 CDT --- (In reply to comment #54)
It seems the Wine bug is that it needs to protect the libraries it uses -- at least libX11/libxcb -- from that sort of abrupt termination, I guess using signal handlers.
Um, I meant "signal masks" there, not "handlers".
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #57 from Henri Verbeet hverbeet@gmail.com 2012-10-28 16:20:21 CDT --- (In reply to comment #53)
The problem is that you really do want to flush the surface before waiting on events. You can't have unflushed drawing pending for indefinite periods, especially if the the user is supposed to be reacting to whatever is supposed to have been drawn.
I suppose you could flush before queueing the message if this is really an issue, but it seems a bit questionable to me to flush on every wait_message() in the first place. I'd imagine you only want to flush after specific events like e.g. paints.
(In reply to comment #54)
The only mechanism I can see is from the wineserver's kill_thread() sending SIGQUIT, causing (inside of ntdll) quit_handler() -> abort_thread() -> terminate_thread() -> pthread_exit().
Is that what's happening?
Yes. It's more or less equivalent to calling pthread_cancel() on the remote thread, although pthread_cancel() is slightly nicer because it gives the thread a chance to run its cancellation handlers. Calling pthread_exit() from the signal stack would make that pretty hopeless as well, if anything actually had cancellation handlers.
I don't blame libxcb for failing to properly handle the case where a thread is unceremoniously terminated while within it. It seems the Wine bug is that it needs to protect the libraries it uses -- at least libX11/libxcb -- from that sort of abrupt termination, I guess using signal handlers. (Although such protection may be both impractical and would prevent proper termination of threads while they're blocked in library calls.)
No. TerminateThread() is unsafe in that regard on Windows as well. What's different here is that the TerminateThread() call is actually the result of the original thread sending some WM_USER message, so the thread that does the actual TerminateThread() call knows the thread is supposed to be in a known safe state. (I.e., it's just that anything we do between queueing a message and waiting for its result has to be cancellation safe.)
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #58 from Maxim Velesyuk loz.accs@gmail.com 2012-10-29 06:45:55 CDT --- (In reply to comment #55)
No problem, I thought fix is already in 1.5.16, but looks like upsteam means latest dev version, so I'm gonna try it. Gentoo has ebuild for it, so this shouldnt be a problem.
Thanks for reply.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #59 from Austin English austinenglish@gmail.com 2012-10-29 15:12:45 CDT --- (In reply to comment #49)
Created attachment 42273 [details] patch
Actually, the attached patch seems fairly good at avoiding the issue. I'm not quite familiar enough with all the code to judge how proper this is, but the basic idea is to avoid making X11 calls until message handler has had a chance to finish.
Alexandre committed something similar: http://source.winehq.org/git/wine.git/commitdiff/b7582525a047018b08768e6672c...
that's probably worth retesting with.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #60 from Marcus Meissner marcus@jet.franken.de 2012-10-30 04:07:13 CDT --- FWIW, a libxcb fix for openSUSE 12.2 has been released to its update channel.
with this fix http://cgit.freedesktop.org/xcb/libxcb/commit/?id=23911a707b8845bff52cd7853f...
http://bugs.winehq.org/show_bug.cgi?id=31882
Scott Ritchie scott@open-vote.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott@open-vote.org
--- Comment #61 from Scott Ritchie scott@open-vote.org 2012-10-30 05:50:09 CDT --- Ubuntu has also shipped the fix for libxcb to 12.04 and later: https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/1059276
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #62 from puthre@gmail.com 2012-10-30 06:00:23 CDT --- (In reply to comment #34)
I get 'err:ntdll:RtlpWaitForCriticalSection section 0x10c95f0c "bitblt.c: surface" wait timed out in thread 0009, blocked by 0040, retrying (60 sec)' every few minutes in Adobe Fireworks CS3 with wine-1.5.15, in Ubuntu 12.04.1 LTS. Fireworks it's unusable right now.
My problem was fixed by the latest ubuntu update on libxcb.
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #63 from Josh DuBois duboisj@codeweavers.com 2012-10-30 15:22:26 CDT --- (In reply to comment #59)
Alexandre committed something similar: http://source.winehq.org/git/wine.git/commitdiff/b7582525a047018b08768e6672c...
that's probably worth retesting with.
This fixes the problem I had with corefonts on my ubuntu 11.10 vm. (tested 200 times in a loop).
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #64 from Ken Sharp kennybobs@o2.co.uk 2012-11-08 08:25:16 CST --- This is causing frequent crashes in old versions of Symantec's LiveUpdate, even with all the updates installed. Looks like it's not solved.
Winedbg crashes too, so there's no trace available.
http://bugs.winehq.org/show_bug.cgi?id=31882
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thumbtack2007@verizon.net
--- Comment #65 from Alexandre Julliard julliard@winehq.org 2012-11-22 04:03:55 CST --- *** Bug 32267 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=31882
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |linuxhippy@gmail.com
--- Comment #66 from Bruno Jesus 00cpxxx@gmail.com 2012-12-03 12:16:31 CST --- *** Bug 32357 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #67 from salamander purake salamanderrake@gmail.com 2012-12-13 13:01:51 CST --- Created attachment 42795 --> http://bugs.winehq.org/attachment.cgi?id=42795 Terminal output showing lock still there even in libxcb 1.9
the patch was sent up stream but It still didnt fix the issue in all applications. the threads still lock in "The Ship"
This is the message I get in a popup box. SteamStartup() failed: SteamStartup(0xf, 0x0033D8B8) failed with error 1: failed to take master pipe connection lock
http://bugs.winehq.org/show_bug.cgi?id=31882
--- Comment #68 from Erich Hoover ehoover@mines.edu 2012-12-13 15:01:42 CST --- (In reply to comment #67)
Created attachment 42795 [details] Terminal output showing lock still there even in libxcb 1.9 ...
Did you do a backtrace to make sure the problem is in libxcb?
http://bugs.winehq.org/show_bug.cgi?id=31882
jolie r. quiescere+winebugs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |quiescere+winebugs@gmail.co | |m
--- Comment #69 from jolie r. quiescere+winebugs@gmail.com 2012-12-13 21:44:11 CST --- *** Bug 32184 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=31882
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mikejbond@gmail.com
--- Comment #70 from Anastasius Focht focht@gmx.net 2013-01-08 13:49:00 CST --- *** Bug 32684 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=31882
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |the.minecraftian.daily@gmai | |l.com
--- Comment #71 from Anastasius Focht focht@gmx.net 2013-05-03 05:58:47 CDT --- *** Bug 32528 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=31882
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johannesobermayr@gmx.de
--- Comment #72 from Austin English austinenglish@gmail.com --- *** Bug 35632 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=31882
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #73 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=31882
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED
--- Comment #74 from Austin English austinenglish@gmail.com --- This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should only be closed when fixed upstream.
Setting back to RESOLVED NOTOURBUG.
Sorry for the spam.
https://bugs.winehq.org/show_bug.cgi?id=31882
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=31882
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://downloads.sourceforg |https://web.archive.org/web |e.net/project/corefonts/the |/20180219204401/https://mir |%20fonts/final/arial32.exe |rors.kernel.org/gentoo/dist | |files/arial32.exe
https://bugs.winehq.org/show_bug.cgi?id=31882
TIMenderslime@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |TIMenderslime@gmail.com
-
wine-bugs＠winehq.org -
WineHQ Bugzilla