DRI2GetBuffersWithFormat hangs waiting for X.org

Tue Nov 30 08:22:54 PST 2010

Hi all,

I'm looking for some expert opinion to verify a possible cause of our
problems.

After further investigation of the issue the following is found:
We do all our X drawing on a single thread.
However, DirectFB (used due to legacy reasons) creates a second thread
for reading inputs (events).

Could this multi-threaded usage of libX11 cause it to hang?

What we see is that our drawing thread gets stuck in a poll on the
socket while calling _XReply (after _XReply has called _XSend). However,
a second thread is seen reading from a socket for inputs.

Thanks,

- Joris Dobbelsteen

On Fri, 2010-11-26 at 18:14 +0100, Joris Dobbelsteen wrote:
> Hi all,
> 
> I'm having an application which is hanging after a call to
> DRI2GetBuffersWithFormat in mesa.
> 
> I am looking for support with the issue and how to diagnose it.
> 
> The issue is that our application is hanging at some point waiting for
> the X server to respond.
> One workaround is to move the mouse, which seems to generate events and
> that makes the communication get back on track.
> 
> The issue has been very consistent, occurring at most 5 minutes after
> the x server is started and usually sooner. The issue does not occur in
> Ubuntu 10.10, which means there is a difference somewhere.
> 
> The stack trace for the X client we are consistently getting is:
> #0  0xb7741424 in __kernel_vsyscall ()
> #1  0xb6d269b4 in pthread_cond_wait () from /lib/libpthread.so.0
> #2  0xb6a03344 in ?? () from /usr/lib/libX11.so.6
> #3  0xb6a02d2f in ?? () from /usr/lib/libX11.so.6
> #4  0xb6a1e0d3 in _XReply () from /usr/lib/libX11.so.6
> #5  0xb5de69a3 in DRI2GetBuffersWithFormat (dpy=0x8397fa0, 
> drawable=10485772, width=0x88dd5a4, height=0x88dd5a8, 
> attachments=0xbfaf0098, count=1,
>      outCount=0xbfaf00c4) at dri2.c:454
> #6  0xb5de478f in dri2GetBuffersWithFormat (driDrawable=0x88dd580, 
> width=0x88dd5a4, height=0x88dd5a8, attachments=0xbfaf0098, count=1, 
> out_count=0xbfaf00c4,
>      loaderPrivate=0x88dd4e0) at dri2_glx.c:582
> #7  0xb5a7d3df in intel_update_renderbuffers (context=0x835f260, 
> drawable=0x88dd580) at intel_context.c:290
> #8  0xb5a7d8cc in intel_prepare_render (intel=0x83997c0) at 
> intel_context.c:438
> #9  0xb5a7a99d in i915_render_start (intel=0x83997c0) at i915_vtbl.c:58
> #10 0xb5a8ed9b in intelRenderStart (ctx=0x83997c0) at intel_tris.c:1087
> #11 0xb5b888b3 in run_render (ctx=0x83997c0, stage=0x8607d88) at 
> tnl/t_vb_render.c:276
> #12 0xb5b7cb84 in _tnl_run_pipeline (ctx=0x83997c0) at tnl/t_pipeline.c:153
> #13 0xb5a8f07d in intelRunPipeline (ctx=0x83997c0) at intel_tris.c:1075
> #14 0xb5b7d284 in _tnl_draw_prims (ctx=0x83997c0, arrays=0x85f5e1c, 
> prim=0x85f47f0, nr_prims=1, ib=0x0, min_index=0, max_index=3) at 
> tnl/t_draw.c:478
> #15 0xb5b7dd86 in _tnl_vbo_draw_prims (ctx=0x83997c0, arrays=0x85f5e1c, 
> prim=0x85f47f0, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', 
> min_index=0,
>      max_index=3) at tnl/t_draw.c:384
> #16 0xb5b75667 in vbo_exec_vtx_flush (exec=0x85f46b8, unmap=1 '\001') at 
> vbo/vbo_exec_draw.c:384
> #17 0xb5b72560 in vbo_exec_FlushVertices_internal (ctx=0x83997c0, 
> unmap=0 '\0') at vbo/vbo_exec_api.c:876
> #18 0xb5b72638 in vbo_exec_FlushVertices (ctx=0x83997c0, flags=1) at 
> vbo/vbo_exec_api.c:910
> #19 0xb5b4bb79 in _mesa_BindTexture (target=34037, texName=19) at 
> main/texobj.c:1058
> #20 0xb5df80b1 in glBindTexture (target=34037, texture=19) at 
> ../../../src/mapi/glapi/glapitemp.h:1627
> #21 0xb4a10e44 in glSetState () from 
> /usr/lib/directfb-1.4-5-pure/gfxdrivers/libdirectfb_gl.so
> #22 0xb6dc3ee1 in ?? () from /usr/lib/libdirectfb-1.4.so.5
> #23 0xb6dc698c in dfb_gfxcard_blit () from /usr/lib/libdirectfb-1.4.so.5
> #24 0xb6d78679 in ?? () from /usr/lib/libdirectfb-1.4.so.5
> #25 0xb6e01825 in IDirectFBSurface::Blit () from /usr/lib/lib++dfb-1.0.so.0
> 
> I see the X server getting a request and sending a reply. After this
> it's back in the waiting for command state:
> 
> #0  0xb76fb424 in __kernel_vsyscall ()
> #1  0xb73c07cd in select () from /lib/libc.so.6
> #2  0x0809bb28 in WaitForSomething ()
> #3  0x0806e0ae in ?? ()
> #4  0x092b0da8 in ?? ()
> #5  0x00000002 in ?? ()
> #6  0x00000000 in ?? ()
> 
> With DEBUG_COMMUNICATION in os/io.c defined, I see the following output:
> [snip]
> REPLY: ClientIDX: 6 XEvent: type: 0xe detail: 0x0 seq#: 0x161b
> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5
> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0xe1 len: 5 seq#: 0x161c
> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5
> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0x63 len: 5 seq#: 0x161d
> REQUEST: ClientIDX: 6, type: 0x3e data: 0x7 len: 7
> REPLY: ClientIDX: 6 XEvent: type: 0xe detail: 0x0 seq#: 0x161e
> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5
> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0xe1 len: 5 seq#: 0x161f
> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5
> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0x63 len: 5 seq#: 0x1620
> REQUEST: ClientIDX: 6, type: 0x3e data: 0x7 len: 7
> REPLY: ClientIDX: 6 XEvent: type: 0xe detail: 0x0 seq#: 0x1621
> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5
> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0xe1 len: 5 seq#: 0x1622
> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5
> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0x63 len: 5 seq#: 0x1623
> REQUEST: ClientIDX: 6, type: 0x3e data: 0x7 len: 7
> REPLY: ClientIDX: 6 XEvent: type: 0xe detail: 0x0 seq#: 0x1624
> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5
> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0xe1 len: 5 seq#: 0x1625
> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5
> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0x63 len: 5 seq#: 0x1626
> REQUEST: ClientIDX: 6, type: 0x3e data: 0x7 len: 7
> REPLY: ClientIDX: 6 XEvent: type: 0xe detail: 0x0 seq#: 0x1627
> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5
> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0xe1 len: 5 seq#: 0x1628
> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5
> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0x63 len: 5 seq#: 0x1629
> REQUEST: ClientIDX: 6, type: 0x3e data: 0x7 len: 7
> REPLY: ClientIDX: 6 XEvent: type: 0xe detail: 0x0 seq#: 0x162a
> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5
> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0xe1 len: 5 seq#: 0x162b
> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5
> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0x63 len: 5 seq#: 0x162c
> 
> It keeps waiting there till I move the mouse and see more REPLY
> responses in a line.
> 
> There is the faint impression that the xserver does something wrong with
> buffering the message, and not flushing it. What is the right approach
> to see when the message is actually written to the socket?
> There seems to be quite a lot of cleverness around writing to the
> socket, probably for performance reasons.
> 
> 
> Note: this is the same issue as:
> <http://lists.freedesktop.org/archives/intel-gfx/2010-November/008850.html>
> 
> Used software (somewhat updated in the meanwhile):
> * Linux 2.6.37-rc3, but same issue with 2.6.36 (and I think with 2.5.35
> as well, but I'm not completely sure).
> * mesa 7.9.
> * xf86-video-intel 2.12.0, 2.13.0, 2.13.901.
> * libdrm 2.4.22 (and today's trunk, as it had a lot of intel patches).
> 
> The issue looks very much the same as:
> <http://www.pubbs.net/201003/xorg/2227-problem-using-an-mesa-based-app-with-recent-xorgmesaxf86-video-intelloop.html>
> 
> Thanks in advance,
> 
> - Joris
> 
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
> 