[Webkit-unassigned] [Bug 206162] [GTK][GStreamer] segfault in webKitWebSrcMakeRequest (libwebkit2gtk-4.0.so.37.39.3)

[bugzilla-daemon at webkit.org]

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

Alicia Boya García <aboya at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |aboya at igalia.com
         Resolution|---                         |DUPLICATE

--- Comment #3 from Alicia Boya García <aboya at igalia.com> ---
Since this bug was opened https://bugs.webkit.org/show_bug.cgi?id=210284 has been landed, which introduced many stability improvements on callbacks like this, therefore I'm closing the bug.

I will note that the `player` field is guaranteed to be set to != nullptr before this callback is set. Therefore (and since it's a plain old pointer), if MediaPlayer was destroyed, it would still not be NULL, it would be a dangling pointer.

But a dangling pointer access to `player` should not happen in the new code base because:

1) WebKitWebSrc is part of the GStreamer pipeline which is owned by MediaPlayerPrivateGStreamer. Tearing this pipeline down includes stopping the WebKitWebSrc streaming thread AND atomically cancelling callbacks using it (by taking the DataMutex lock and increasing the requestNumber, see webKitWebSrcStop() and webKitWebSrcUnLock()).

2) In order to access `player` from a callback in the new code base, the DataMutex has to be locked. Then the requestNumber is checked to make sure the task is still relevant, exiting early otherwise. All usages of `player` in the current codebase are done while this mutex is locked.

Of course, if despite this analysis you end up finding a similar crash in a version of WebKit that includes the aforementioned commit, please post it in a new bug for investigation.

*** This bug has been marked as a duplicate of bug 210284 ***

-- 
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/20200512/5ee160f9/attachment-0001.htm>