Bug 83567 – [BlackBerry] Crash when tearing down web page rendered using WebPageCompositor

• Component: WebKit BlackBerry
• Status: RESOLVED FIXED

[Arvid Nilsson]

This happens when the WebPage::setVisible(false) is called as part of tearing down a WebPage. This calls suspendRootLayerCommit() which schedules destroyLayerResources() on the UI thread. UI thread call stack:

WebCore::LayerRenderer::releaseLayerResources (this=0x0)
    at /home/anilsson/dev/webkit/Source/WebCore/platform/graphics/blackberry/LayerRenderer.cpp:191
191	    if (m_hardwareCompositing) {
(gdb) p this
$1 = (WebCore::LayerRenderer * const) 0x0
(gdb) bt
#0  WebCore::LayerRenderer::releaseLayerResources (this=0x0)
    at /home/anilsson/dev/webkit/Source/WebCore/platform/graphics/blackberry/LayerRenderer.cpp:191
#1  0x7925dc2c in BlackBerry::WebKit::WebPageCompositorPrivate::releaseLayerResources (this=<optimized out>)
    at /home/anilsson/dev/webkit/Source/WebKit/blackberry/Api/WebPageCompositor.cpp:146
#2  0x7924c726 in BlackBerry::WebKit::WebPagePrivate::destroyLayerResources (
    this=<optimized out>)
    at /home/anilsson/dev/webkit/Source/WebKit/blackberry/Api/WebPage.cpp:5566
#3  0x7925c3aa in BlackBerry::Platform::MethodDelegate0<void (BlackBerry::WebKit::WebPagePrivate::*)(), BlackBerry::WebKit::WebPagePrivate>::execute (
    this=0xb7e980)
    at /home/anilsson/dev/staging/usr/include/browser/platform/BlackBerryPlatformMessageDelegate.h:770
#4  0x7a05ff98 in BlackBerry::Platform::ExecutableMessage::execute (
    this=<optimized out>)
    at /home/anilsson/dev/platform/blackberryplatform/BlackBerryPlatformExecutableMessage.cpp:38
...

[Arvid Nilsson]

Created attachment 136435 [details]
Patch

[Antonio Gomes]

Comment on attachment 136435 [details]
Patch

so if the mlayerRenderer is null, "resources" were already released?

[Arvid Nilsson]

(In reply to comment #2)
> (From update of attachment 136435 [details])
> so if the mlayerRenderer is null, "resources" were already released?

Yes, or you could see it this way - the LayerRenderer owns the resources that should be released, so if there's no LayerRenderer, there are no resources to delete. Resources = textures right now, but could be more stuff in the future (for example shaders).

[Antonio Gomes]

Comment on attachment 136435 [details]
Patch

(In reply to comment #3)
> (In reply to comment #2)
> > (From update of attachment 136435 [details] [details])
> > so if the mlayerRenderer is null, "resources" were already released?
> 
> Yes, or you could see it this way - the LayerRenderer owns the resources that should be released, so if there's no LayerRenderer, there are no resources to delete. Resources = textures right now, but could be more stuff in the future (for example shaders).

Ok. I was wondering was would be the codepath be...

[Arvid Nilsson]

(In reply to comment #4)
> (From update of attachment 136435 [details])
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (From update of attachment 136435 [details] [details] [details])
> > > so if the mlayerRenderer is null, "resources" were already released?
> > 
> > Yes, or you could see it this way - the LayerRenderer owns the resources that should be released, so if there's no LayerRenderer, there are no resources to delete. Resources = textures right now, but could be more stuff in the future (for example shaders).
> 
> Ok. I was wondering was would be the codepath be...

Right now, it's probably due to an earlier call to WebPageCompositor::cleanup() that would clear the layer renderer. The layer rendrrer destructor then releases the resources.

[WebKit Review Bot]

Comment on attachment 136435 [details]
Patch

Clearing flags on attachment: 136435

Committed r113757: <http://trac.webkit.org/changeset/113757>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.