[Webkit-unassigned] [Bug 184583] New: REGRESSION(r230627): [GTK][WPE] Possible deadlock when destroying the player in non AC mode

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Apr 13 04:23:57 PDT 2018


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

            Bug ID: 184583
           Summary: REGRESSION(r230627): [GTK][WPE] Possible deadlock when
                    destroying the player in non AC mode
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: magomez at igalia.com
                CC: bugs-noreply at webkitgtk.org

In my effort to simplify the code in the patch for https://bugs.webkit.org/show_bug.cgi?id=183362 I accidentally added the possibility of a deadlock between the main and gstreamer threads when not in AC mode.

The thing is that when the player destructor is running, there's the possibility that a call to triggerRepaint() is being executed in the gstreamer thread. After r230627 it's possible that cancelRepaint() called from the destructor is executed before triggerRepaint() waits in the m_drawCondition, which means that the gstreamer thread will be locked forever.

The fix here is to put m_destroying inside cancelRepaint() again, and modify it inside the same lock where we notify m_drawCondition. And also check its value in triggerRepaint() inside the m_drawMutex lock. That way, if cancelRepaint() gets executed before triggerRepaint() reaches the lock, triggerRepaint will exit before waiting in the condition, and if cancelRepaint() is executed after triggerRepaint() reaches the lock it will signal the m_drawCondition an release the gstreamer thread.

I'll send a patch in a while and then punish myself writing 500 times "watch out with the race conditions" :(

-- 
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/20180413/0462da59/attachment.html>


More information about the webkit-unassigned mailing list