<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - hang in xcb_wait_for_reply / vl_dri2_get_flush_reply" href="https://bugs.freedesktop.org/show_bug.cgi?id=93414#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - hang in xcb_wait_for_reply / vl_dri2_get_flush_reply" href="https://bugs.freedesktop.org/show_bug.cgi?id=93414">bug 93414</a> from <a class="email" href="mailto:vliaskov@gmail.com" title="Vasilis LIaskovitis <vliaskov@gmail.com>"> Vasilis LIaskovitis</a> <pre>(In reply to Uli Schlachter from <a href="show_bug.cgi?id=93414#c3">comment #3</a>) > (In reply to Vasilis LIaskovitis from <a href="show_bug.cgi?id=93414#c0">comment #0</a>) > [...] > > 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: <a href="http://pastebin.com/rQCJm64C">http://pastebin.com/rQCJm64C</a> > > 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)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>