Crash in lambda function WTF::Function<void ()>::CallableWrapper<WebKit::DisplayLink...
authorpvollan@apple.com <pvollan@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 7 Jun 2018 00:42:43 +0000 (00:42 +0000)
committerpvollan@apple.com <pvollan@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 7 Jun 2018 00:42:43 +0000 (00:42 +0000)
commit0462bd145753f8c0369e3500d49f0331927ed47f
tree79e5945288d278a3aa4e20b0c8bd7d070344a628
parent20e80cc1af46f90cea4366a188039bc0a8cefcc1
Crash in lambda function WTF::Function<void ()>::CallableWrapper<WebKit::DisplayLink::displayLinkCallback
https://bugs.webkit.org/show_bug.cgi?id=186370
<rdar://problem/39791647>

Reviewed by Brent Fulgham.

When the display link is firing, the callback function is called on the display link thread, where a lambda function
is created to be executed on the main thread. The WebPageProxy object is captured as a RefPtr in the lambda. This
might crash when executing on the main thread, since the WebPageProxy object is possibly deleted then. Capturing
the WebPageProxy will not prevent the object from being deleted if the destruction of the WebPageProxy object already
has started on the main thread when the object is captured, which sometimes is the case. Instead, we can create a
weak pointer to the object, which will work as intended, even if the WebPageProxy object is in the process of being
deleted. This also matches the display link implementation used when the WebContent process has access to the
WindowServer. This is not a frequent crash. I have not been able to reproduce it.

* UIProcess/mac/DisplayLink.cpp:
(WebKit::DisplayLink::displayLinkCallback):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@232564 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebKit/ChangeLog
Source/WebKit/UIProcess/mac/DisplayLink.cpp