Changeset 118702 in webkit

Timestamp:

May 28, 2012 12:21:23 PM (12 years ago)

Author:

commit-queue@webkit.org

Message:

[BlackBerry] Dangling pointer in WebPagePrivate::setCompositor() message
​https://bugs.webkit.org/show_bug.cgi?id=87590

Patch by Arvid Nilsson <​anilsson@rim.com> on 2012-05-28
Reviewed by Rob Buis.

A crash would be seen in GuardedPointerBase::getWithGuardLocked when
attempting to unpickle and execute serialized call to setCompositor.

The problem was that the message had been created with a dangling
pointer as the target. The web page failed to inform its compositor
that it was being destroyed due to an early return in
WebPagePrivate::destroyCompositor.

The root cause was that a method called "destroyCompositor" was being
called in two situations, when navigating to a new page as well as when
actually deleting the web page. And in one case, we really only wanted
to free up some memory by clearing textures, while in the other case we
really did want to destroy the compositor.

Fixed by calling a method to release textures when that's what we want
to do, and calling a method to destroy the compositor when that's what
we want to do, and making that latter method unconditional.

Reviewed internally by Jeff Rogers.

PR #156765

• Api/WebPage.cpp:

(BlackBerry::WebKit::WebPagePrivate::setLoadState):
(BlackBerry::WebKit::WebPagePrivate::destroyCompositor):

Location:

trunk/Source/WebKit/blackberry

Files:

• Api/WebPage.cpp (modified) (2 diffs)
• ChangeLog (modified) (1 diff)

trunk/Source/WebKit/blackberry/Api/WebPage.cpp

@@ -885 +885 @@
 
 #if USE(ACCELERATED_COMPOSITING)
-            if (isAcceleratedCompositingActive() && !compositorDrawsRootLayer())
-                syncDestroyCompositorOnCompositingThread();
+            if (isAcceleratedCompositingActive()) {
+                Platform::userInterfaceThreadMessageClient()->dispatchSyncMessage(
+                    Platform::createMethodCallMessage(&WebPagePrivate::destroyLayerResources, this));
+            }
 #endif
             m_previousContentsSize = IntSize();
@@ -5896 +5898 @@
 void WebPagePrivate::destroyCompositor()
 {
-    // We shouldn't release the compositor unless we created and own the
-    // context. If the compositor was created from the WebPageCompositor API,
-    // keep it around and reuse it later.
-    if (!m_ownedContext)
-        return;
-
     // m_compositor is a RefPtr, so it may live on beyond this point.
     // Disconnect the compositor from us

trunk/Source/WebKit/blackberry/ChangeLog

@@ +1 @@
+2012-05-28  Arvid Nilsson  <anilsson@rim.com>
+
+        [BlackBerry] Dangling pointer in WebPagePrivate::setCompositor() message
+        https://bugs.webkit.org/show_bug.cgi?id=87590
+
+        Reviewed by Rob Buis.
+
+        A crash would be seen in GuardedPointerBase::getWithGuardLocked when
+        attempting to unpickle and execute serialized call to setCompositor.
+
+        The problem was that the message had been created with a dangling
+        pointer as the target. The web page failed to inform its compositor
+        that it was being destroyed due to an early return in
+        WebPagePrivate::destroyCompositor.
+
+        The root cause was that a method called "destroyCompositor" was being
+        called in two situations, when navigating to a new page as well as when
+        actually deleting the web page. And in one case, we really only wanted
+        to free up some memory by clearing textures, while in the other case we
+        really did want to destroy the compositor.
+
+        Fixed by calling a method to release textures when that's what we want
+        to do, and calling a method to destroy the compositor when that's what
+        we want to do, and making that latter method unconditional.
+
+        Reviewed internally by Jeff Rogers.
+
+        PR #156765
+
+        * Api/WebPage.cpp:
+        (BlackBerry::WebKit::WebPagePrivate::setLoadState):
+        (BlackBerry::WebKit::WebPagePrivate::destroyCompositor):
+
 2012-05-28  Arvid Nilsson  <anilsson@rim.com>