Wine locks up when running multithreaded applications that touch both OpenGL and X11
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libxcb |
Fix Released
|
Medium
|
|||
libxcb (Ubuntu) |
Fix Released
|
Medium
|
Canonical X.org | ||
Precise |
Fix Released
|
Medium
|
Unassigned |
Bug Description
[IMPACT]
Wine needs an update to libxcb to include upstream commit 23911a707b8845b
[TESTCASE 1 - No wine required]
1) download https:/
2) compile and run: --- gcc -o test t.c -lxcb -lpthread; ./test
3) When broken (without the patch) you'll just see "o" repeating over and over, when working properly (with the patch) you'll see both "o" and "x" appearing in the output.
[TESTCASE 2 - Wine required]
1) download http://
2) run wine graphics.exe and watch for it to get hung.
3) It should fade out or be hung on a green screen soon after launch without the fix.
[Regression Potential]
This patch is in the stable libxcb 1.9 which was just released last week. There has been no known fallout from it being in quantal for 2 weeks.
Changed in libxcb (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Medium |
assignee: | nobody → Canonical X.org (canonical-x) |
description: | updated |
tags: | added: patch |
tags: | added: precise quantal |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Changed in libxcb: | |
importance: | Unknown → Medium |
status: | Unknown → Fix Released |
description: | updated |
Now that Wine is no longer locking around all X calls we're seeing lockups in applications that use both OpenGL (through Direct3D) and X11 (through GDI) simultaneously in separate threads. It appears that something strange is happening in _XReply that causes the applications to hang indefinitely in xcb_wait_for_reply when both threads happen to use the same sequence number at the same time.
I'm not really an X expert, so I'd really appreciate some help trying to track this down. On the Wine end we have a bug open (http:// bugs.winehq. org/show_ bug.cgi? id=31406) to track this issue, but we're pretty sure it's something in xlib or xcb.