X11 server not reply to glXCreateGLXPixmap(), cause client deadlock

[drangon.mail@…]

Mac OS X 10.7 (Lion) XQuartz-2.6.3 wine-1.3.28

wine call glXCreateGLXPixmap(), but the server don't reply, call wine to wait for reply forever.

the client backtrace is :

(gdb) bt
#0  0x9b1adb42 in select$DARWIN_EXTSN ()
#1  0x450428f3 in _xcb_in_read_block ()
#2  0x45042d05 in _xcb_in_read ()
#3  0x45041af5 in _xcb_conn_wait ()
#4  0x45043565 in xcb_wait_for_reply ()
#5  0x44f5056f in _XReply ()
#6  0x4536296d in XAppleDRICreatePixmap ()
#7  0x45356a9a in apple_glx_pixmap_create ()
#8  0x45364f72 in glXCreateGLXPixmap ()
#9  0x44d5bba6 in set_win_format [inlined] () at
/opt/wine-zjg/src/wine-1.3.28/dlls/winex11.drv/window.c:622
#10 0x44d5bba6 in X11DRV_WindowMessage (hwnd=0x21696, msg=14, wp=186, lp=0) at
window.c:2692
#11 0x42669fc4 in handle_internal_message (hwnd=0x21696, msg=<value temporarily
unavailable, due to optimizations>, wparam=186, lparam=0) at message.c:1882
#12 0x4266a0dd in call_window_proc (hwnd=<value temporarily unavailable, due to
optimizations>, msg=<value temporarily unavailable, due to optimizations>,
wparam=186, lparam=0, unicode=1, same_thread=1, mapping=2949708) at
message.c:2198

[drangon.mail@…]

(gdb) bt
#0  0x9b1adb42 in select$DARWIN_EXTSN ()
#1  0x450428f3 in _xcb_in_read_block ()
#2  0x45042d05 in _xcb_in_read ()
#3  0x45041af5 in _xcb_conn_wait ()
#4  0x45043565 in xcb_wait_for_reply ()
#5  0x44f5056f in _XReply ()
#6  0x4536296d in XAppleDRICreatePixmap ()
#7  0x45356a9a in apple_glx_pixmap_create ()
#8  0x45364f72 in glXCreateGLXPixmap ()
#9  0x44d5bba6 in set_win_format [inlined] () at
/opt/wine-zjg/src/wine-1.3.28/dlls/winex11.drv/window.c:622
#10 0x44d5bba6 in X11DRV_WindowMessage (hwnd=0x21696, msg=14, wp=186, lp=0) at
window.c:2692
#11 0x42669fc4 in handle_internal_message (hwnd=0x21696, msg=<value temporarily
unavailable, due to optimizations>, wparam=186, lparam=0) at message.c:1882
#12 0x4266a0dd in call_window_proc (hwnd=<value temporarily unavailable, due to
optimizations>, msg=<value temporarily unavailable, due to optimizations>,
wparam=186, lparam=0, unicode=1, same_thread=1, mapping=2949708) at
message.c:2198

[jeremyhu@…]

Please try XQuartz-2.7.0_beta1, I'm pretty sure I fixed that already. If not, it's probably gonna be in beta2.

[drangon.mail@…]

XQuartz-2.7.0_beta1 still has the problem, when will beta2 come out ?

[drangon.mail@…]

I compile the xorg-server-1.11.0.tar.bz2 to test, the problem still exist.

[drangon.mail@…]

I use gdb to debug into xorg-server-1.11.0 code, set a breakpoint on ProcAppleDRICreatePixmap(), then use "s" cmd to step forward, after some step, I got a "signal SIGALRM", and the "s" cmd block forever.

[drangon.mail@…]

It is said that Mac OS X 10.7.2 update will fix this problem, I'm going to try it.

[jeremyhu@…]

Replying to drangon.mail@…:

It is said that Mac OS X 10.7.2 update will fix this problem, I'm going to try it.

Where is it said that?

Also, as mentioned above, this should be fixed in 2.7.0_beta2. Please try that version.

[jeremyhu@…]

No, it looks like the change isn't there... hrm, did I forget to push it?

[eartemov@…]

Jeremy, could you, please, give me a patch so that I can demonstrate to their customers that this bug is already fixed? Our customers are very concerned that our application still can not work under OSX Lion.

[eartemov@…]

Cc Me!

[jeremyhu@…]

I don't have a patch for this yet. When I do, I will let you know here. This is one of only a couple issues holding up the 2.7.0 release, and I hope to have time to address it at some point in the next 6 weeks, but I can't say when that will be or how likely I am to actually come up with something for 2.7.0.

If you can provide additional information, that will certainly help. Can you tell me what version of the server or mesa introduced this problem? Narrowing it down to a specific release of XQuartz and its betas will help get us most of the way there, and we can probably bisect back from that point.

​http://static.macosforge.org/xquartz/downloads/SL/

Some of the earlier versions require SL and will fail on Lion, so I suggest you use SL to surf through these back versions.

[jeremyhu@…]

Yeah, I spent some time looking into this, and it seems like a bug in XAppleDRICreatePixmap... either the client is leaving leftover data on the wire or the client isn't sending enough. I have a reduced test case which causes an assertion failure during an XSync() immediately after XAppleDRICreatePixmap, and I suspect this is just another incarnation of the same underlying issue.

[jeremyhu@…]

Ok, I know what the problem is and will try to get a fix on Monday or Tuesday

[jeremyhu@…]

Ok, I think I have a fix for the *server* issue here. With these fixes, my glxpixmap teste suite passes when using mesa-7.10.x. I've pushed the changes to my branch for eventual integration: ​http://cgit.freedesktop.org/~jeremyhu/xserver

As I mentioned, this makes it work with Mesa-7.10.x. Mesa-7.11 has a failure that I'm still looking into, but it gets past this particular bug.

[jeremyhu@…]

Fixed one of the mesa bugs with initializing the GLXPixmap here: ​http://cgit.freedesktop.org/~jeremyhu/mesa/commit/?id=759fc598cf5885ab55bb7151fde7f2ef2eb43f68

but still not passing the create_destroy loop test.

[jeremyhu@…]

Ok, this bug is fixed and will land in beta4. I'll track the other GLXPixmap regressions separately.