Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 2b7262df1ad38a5e28bfd3abf78f103a8e25fded
https://github.com/WebKit/WebKit/commit/2b7262df1ad38a5e28bfd3abf78f103a8e25fded
Author: Abrar Rahman Protyasha <[email protected]>
Date: 2026-05-28 (Thu, 28 May 2026)
Changed paths:
M
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h
M
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm
M
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.h
M
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.mm
Log Message:
-----------
Occasional UI process crash under DisplayLink callbacks for RemoteLayerTree
DisplayLink clients
https://bugs.webkit.org/show_bug.cgi?id=315775
rdar://178074044
Reviewed by Megan Gardner, Zak Ridouh, and Richard Robinson.
Each DisplayLink client is responsible for removing its own entry from
the DisplayLinkCollection map before destruction, otherwise subsequent
callbacks call into a CheckedRef that points to zero'd memory. This
latent issue may have become more deterministic following 302438@main
and 310357@main, which forced DisplayLink::Client to be heap-allocated
and made the CheckedPtr zombie path resilient to dead-store elimination
optimizations, respectively.
This commit follows up from 313698@main, where we fixed this issue for
SwipeProgressTracker. The same pattern is present in two other clients,
both of which gate cleanup on an existingDisplayLink() lookup that
requires page()/*m_displayID being valid, namely:
- RemoteLayerTreeDrawingAreaProxyMac::~RemoteLayerTreeDrawingAreaProxyMac
- RemoteLayerTreeEventDispatcher::removeDisplayLinkClient()
We extend the 313698@main fix (and WebProcessProxy's earlier precedent)
here and have both classes (1) cache a WebProcessPool at construction and
(2) route deregistration through DisplayLinkCollection::stopDisplayLinks,
which walks every DisplayLink and removes the client unconditionally.
No new tests, for the same reason as 313698@main: existing harnesses
don't register a DisplayLink::Client deterministically. The necessary
test support can land in a follow-up.
*
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.h:
*
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeDrawingAreaProxyMac.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::RemoteLayerTreeDrawingAreaProxyMac):
(WebKit::RemoteLayerTreeDrawingAreaProxyMac::~RemoteLayerTreeDrawingAreaProxyMac):
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.h:
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.mm:
(WebKit::RemoteLayerTreeEventDispatcher::removeDisplayLinkClient):
Canonical link: https://commits.webkit.org/314099@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
