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" :(
Created attachment 337880 [details] Patch
Comment on attachment 337880 [details] Patch Clearing flags on attachment: 337880 Committed r230629: <https://trac.webkit.org/changeset/230629>
All reviewed patches have been landed. Closing bug.