[Xcb] [Bug 93414] hang in xcb_wait_for_reply / vl_dri2_get_flush_reply

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93414

--- Comment #3 from Uli Schlachter <psychon at znc.in> ---
(In reply to Vasilis LIaskovitis from comment #0)
[...]
> I see a hang in xcb_wait_for_reply() for request #31161:
>  
> Possibly relevant part of xtrace:
> 000:>:4d8a:32: Reply to SwapBuffers: swap_hi=0 swap_lo=31161
> 000:>:4d8b:32: Reply to GetInputFocus: revert-to=Parent(0x02)
> focus=0x02e000e0
> 000:<:24d8c: 20: DRI2-Request(155,7): GetBuffersWithFormat
> drawable=0x04400006 attachments={attachment=BackLeft(0x00000001)
> format=0x00000020};
> 000:>:24d8c: Event DRI2-BufferSwapComplete(102) drawable=0x00000002
> ust_hi=71303174 ust_lo=0 msc_hi=1858207713 msc_lo=0 sbc_hi=109393
> sbc_lo=31161

Why is this part relevant? It's 0x31161-0x24d8c = 50133 requests before the
hang, so apparently things still work for 50k requests. That should be a long
time.

> And:
> 000:<:31161:  4: Request(43): GetInputFocus  
> 000:>:31161: Event DRI2-InvalidateBuffers(103) drawable=0x04400006

So if I understand this correctly, you are saying that requests #31161 is a
GetInputFocus request and xtrace never saw a reply to it, right?
Isn't the bug then in the server for not replying to GetInputFocus?

> Full backtrace at: http://pastebin.com/rQCJm64C

Thread 16 is in radeon_something, waits on a condition
Thread 15 waits for the vaapi lock(?) (pthread_mutex_lock() from within
gst_vaapisink_x11_handle_events())
Thread 14 waits on a condition inside gst_data_queue_push() (hm?!? Is some
queue full, or why does it wait?)
Thread 13 waits on a condition inside gst_task_func (dunno what this is)
Thread 12 waits on a condition inside gst_vaapidecode_handle_frame() (and has a
deep backtrace with lots of gst stuff)
Thread 11 waits in gst_queue_chain_buffer_or_list() (deep backtrace)
Thread 10 waits on a condition inside gst_queue_loop()
Thread 9 waits on a condition inside gst_base_sink_wait_preroll() (deep
backtrace)
Thread 8 poll()s for a reply to request 31161 (called from
vl_dri2_get_flush_reply()) (deep backtrace)
Thread 7 waits on a condition inside ??() in libavcodec.so
So do thread 6, 5, 4, 3.
Thread 2 poll()s something pulseaudio related (pa_mainloop_poll())
Thread 1 *also* poll()s the xcb connection (wait_for_reply() on request 212481,
called from _XReply(), called from DRI2GetBuffersWithFormat, called eventually
from st_Clear() (something from mesa), called from main())

Ohhh... thread 1 and thread 8 wait on different XCB connections. I have no clue
about the internals of mesa etc, but could it be that something did a
GrabServer and that's why the GetInputFocus (and DRI2GetBuffersWithFormat)
isn't replied to? Since each thread involving libxcb has its own connection, I
really don't think that the deadlock is inside of libxcb.

@Vasilis: How do you know that this is a deadlock? Does your X11 server still
work correctly otherwise? I'd expect both of these pending requests to get
replies.

Also, could you do something like this ('thread 1' would switch to, well,
thread 1 and frame 2 to the frame with `_xcb_conn_wait()` so that we get a
reference to the XCB connection, the various prints print the state of the XCB
connection):
thread 1
frame 2
print c
print c.in->current_reply
print c.in->events
print c.in->pending_replies

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20151219/9de814f4/attachment.html>