[Webkit-unassigned] [Bug 247057] [GStreamer] Web process leak caused by hang in ImageDecoderGStreamer::pushEncodedData

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=247057

--- Comment #9 from Michael Catanzaro <mcatanzaro at gnome.org> ---
Created attachment 464127

  --> https://bugs.webkit.org/attachment.cgi?id=464127&action=review

gdb.txt

I believe this deadlock is triggered by visiting articles on cnn.com. Still don't have a reliable reproducer unfortunately, so no GStreamer log, but I did catch three hung web processes today so I got the requested all-threads backtrace, attached.

I notice GStreamer is being used on a *lot* of  different threads here. ImageDecoderGStreamer specifically is in use on three different threads:

 * Thread 1 is calling ImageDecoderGStreamer::pushEncodedData and is blocked on line 463 m_innerDecoder = nullptr, which triggers the call to the callback inside InnerDecoder::preparePipeline, where it waits on line 394 for the condition variable: decoder.m_messageCondition.wait(decoder.m_messageLock).
 * Thread 26 is also waiting in the same callback on line 394, though with a different and much simpler backtrace.
 * Finally, thread 28 is waiting in ImageDecoderGStreamer::setHasEOS on line 294 for the condition variable m_handlerCondition.wait(m_handlerLock).

This is notably a little different from the first backtrace I attached above, where ImageDecoderGStreamer::pushEncodedData was blocked on line 446 instead of line 463. There must be a deadlock here somewhere, but unfortunately I do not see it. (I confused myself a bit at first because I forgot that the condition variable will release its lock.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20221220/554d55e9/attachment.htm>