Title: [118702] trunk/Source/WebKit/blackberry
Revision
118702
Author
[email protected]
Date
2012-05-28 12:21:23 -0700 (Mon, 28 May 2012)

Log Message

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

Patch by Arvid Nilsson <[email protected]> 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):

Modified Paths

Diff

Modified: trunk/Source/WebKit/blackberry/Api/WebPage.cpp (118701 => 118702)


--- trunk/Source/WebKit/blackberry/Api/WebPage.cpp	2012-05-28 18:53:56 UTC (rev 118701)
+++ trunk/Source/WebKit/blackberry/Api/WebPage.cpp	2012-05-28 19:21:23 UTC (rev 118702)
@@ -884,8 +884,10 @@
 #endif
 
 #if USE(ACCELERATED_COMPOSITING)
-            if (isAcceleratedCompositingActive() && !compositorDrawsRootLayer())
-                syncDestroyCompositorOnCompositingThread();
+            if (isAcceleratedCompositingActive()) {
+                Platform::userInterfaceThreadMessageClient()->dispatchSyncMessage(
+                    Platform::createMethodCallMessage(&WebPagePrivate::destroyLayerResources, this));
+            }
 #endif
             m_previousContentsSize = IntSize();
             m_backingStore->d->resetRenderQueue();
@@ -5895,12 +5897,6 @@
 
 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
     m_compositor->setPage(0);

Modified: trunk/Source/WebKit/blackberry/ChangeLog (118701 => 118702)


--- trunk/Source/WebKit/blackberry/ChangeLog	2012-05-28 18:53:56 UTC (rev 118701)
+++ trunk/Source/WebKit/blackberry/ChangeLog	2012-05-28 19:21:23 UTC (rev 118702)
@@ -1,5 +1,38 @@
 2012-05-28  Arvid Nilsson  <[email protected]>
 
+        [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  <[email protected]>
+
         [BlackBerry] Add a default tap highlight
         https://bugs.webkit.org/show_bug.cgi?id=87569
 
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes

Reply via email to