[Webkit-unassigned] [Bug 204648] [iOS] Crash in RenderLayerBacking::updateCompositedBounds from using cleared WeakPtr from m_backingSharingLayers

[bugzilla-daemon at webkit.org]

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

Ali Juma <ajuma at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|webkit-unassigned at lists.web |ajuma at chromium.org
                   |kit.org                     |

--- Comment #6 from Ali Juma <ajuma at chromium.org> ---
Created attachment 385544

  --> https://bugs.webkit.org/attachment.cgi?id=385544&action=review

Minimized test case

Here's a minimized test case.

This bug happens when a RenderLayer X moves from one backingProviderLayer Y to another backingProviderLayer Z that's a descendant of the old backingProviderLayer. When this happens, the old backingProviderLayer (Y) clears out the layer's backingProviderLayer pointer in the call to clearBackingSharingLayerProviders that happens during RenderLayerCompositor::BackingSharingState::updateAfterDescendantTraversal.

So then RenderLayer X appears in Z's m_backingSharingLayers, but X's backingProviderLayer is null. This means that when X is destroyed, it doesn't know that it needs to tell Z about this. The next time we try to use the weak pointer to X in Z's m_backingSharingLayers, we crash.

The fix is to make clearBackingSharingLayerProviders only clear a layer's backingProviderLayer if that backingProviderLayer is the current backing's owner.

-- 
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/20191212/b40b6fab/attachment.htm>