Some wine applications still suffer from deadlocks / crashes which appear traceable to libxcb, even with libcxb1.9 (e.g., even after bug 54671 was fixed). The problem occurs when trying to use wine to install windows core fonts. It is intermittent: many people report hitting it on the order of 1/20 times, with some reports as low as 1/300. In my personal testing on an Ubuntu 11.10 VM running on a MacBook, I hit it > 1/10 and can reproduce it by hand (several folks run the font installers in a loop to see the bug). A coworker who installs fonts regularly throughout the day on real Ubuntu 11.10 machine will hit it several times a day during regular work, without using a script to run the installer in a loop. Winehq bug 31882 has a backtrace of a deadlock here: http://bugs.winehq.org/show_bug.cgi?id=31882#c42 To reproduce: 1.) Install wine 1.15 or greater. 2.) Install libxcb1.9 (or a version with bug libxcb bug 54671 fixed) 3.) Download the arial font installer from: downloads.sourceforge.net/project/corefonts/the%20fonts/final/arial32.exe 4.) Run wine arial32.exe /Q The /Q will minimize the interaction that arial32.exe asks of the user. On ubuntu 11.10 it appears easy to hit the problem after just a few runs. On some systems, you may need to run the installer in a loop. As stated above, frequency of hitting the bug varies, but 1/20 runs seems enough for most people.
Created attachment 69140 [details] Backtrace of deadlock in wine. backtrace of deadlock from running arial32.exe font installer under wine.
The backtrace you provided shows only one thread. Could you try "thread apply all bt full", to get a backtrace of every thread? That could help us find the threads that deadlock together.
(In reply to comment #0) > Some wine applications still suffer from deadlocks / crashes which appear > traceable to libxcb, even with libcxb1.9 (e.g., even after bug 54671 was > fixed). > > 1.) Install wine 1.15 or greater. Should be wine 1.5.15, just avoid confusing :) Cheers.
(In reply to comment #2) > The backtrace you provided shows only one thread. Could you try "thread > apply all bt full", to get a backtrace of every thread? That could help us > find the threads that deadlock together. I will try, but I just lifted that backtrace from the winehq bug: I didn't create it. (I have one which wine itself dumped after a font install crash, but I haven't attached a debugger to a hung font install ... don't have a dev env on the vm I've been testing with, and I'm not expert at wine debugging, generally...). One thing which I should have been more explicit about: the behavior I see is a lengthy hang followed by an eventual crash. I believe (but am not certain) that once the font installer hangs, it will crash every time if left alone for long enough.
Created attachment 69141 [details] Log: Backtrace of deadlock threads Hello, I'm one of lucky people who reproduce the "new deadlock" bug :) I reproduce the deadlock about 1/20, on Ubuntu 11.10, 3.0.0-26-generic-pae, libxcb 1.9, wine-1.5.15 However, as Erich E. Hoover point out in a private email, my deadlock doesn't seem to related with libxcb. I collect the backtrace here, and hopefully that helps, maybe there are more than one deadlock bugs, some people hits on a libxcb bug and some other people hits on another unknown bug like me. Cheers.
(In reply to comment #2) > The backtrace you provided shows only one thread. Could you try "thread > apply all bt full", to get a backtrace of every thread? That could help us > find the threads that deadlock together. Actually the other thread has been killed by TerminateThread, so the data structures are most likely corrupted. Not a libxcb bug.
libxcb is not pthread-cancellation safe (and I think nothing else is either, who came up with thread cancellation anyway?). And the fact that the hang is inside of pthread_signal() is IMHO a strong hint that this is really what went wrong.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.