[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 #4 from Vasilis LIaskovitis <vliaskov at gmail.com> ---
(In reply to Uli Schlachter from comment #3)
> (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.
> 

You are right, this looks irrelevant.. not very familiar xith X protocol, I was
thinking sbc_lo could refer to a request ID.

> > 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

pending_replies is 0

(gdb) print c.in->current_reply
$4 = (struct reply_list *) 0x0
(gdb) print c.in->events
$5 = (struct event_list *) 0x7f0b1c008730
(gdb) print c.in->pending_replies
$6 = (struct pending_reply *) 0x0

Looking at all threads in bt, this may be a completely different issue with
gstreamer queues.. we can maybe close the issue and reopen if I find something
that really proves it is an xcb/xserver issue (or if you have another idea)

-- 
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/20151221/8f5cdeb7/attachment.html>