Bug 123397

Summary: [EFL] ASSERTION FAILED: !m_flushingLayers in several tests
Product: WebKit Reporter: Sergio Correia (qrwteyrutiyoup) <sergio>
Component: New BugsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Normal CC: cmarcelo, commit-queue, gyuyoung.kim, kondapallykalyan, luiz, mcatanzaro, noam, ossy, tonikitoo
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
RFC patch noam: review-

Sergio Correia (qrwteyrutiyoup)
Reported 2013-10-27 09:21:55 PDT
[CoordinatedGraphics] ASSERTION FAILED: !m_flushingLayers in several tests
Attachments
RFC patch (8.11 KB, patch)
2013-10-27 09:27 PDT, Sergio Correia (qrwteyrutiyoup)
noam: review-
Sergio Correia (qrwteyrutiyoup)
Comment 1 2013-10-27 09:24:47 PDT
In CompositingCoordinator::flushPendingLayerChanges() we indicate we are in the middle of a flush, to prevent calling scheduleLayerFlush() inside flushCompositingState(), but in some code paths we don't go through it and end up calling scheduleLayerFlush() when we shouldn't. This causes several layout tests (approx. 1.7K on Nix, probably a similar amount on EFL, but I wasn't able to finish running the layout tests due to technical problems) to crash hitting this assert.
Sergio Correia (qrwteyrutiyoup)
Comment 2 2013-10-27 09:27:31 PDT
Created attachment 215272 [details] RFC patch RFC patch indicating we are in the middle of a flush in flushCompositingState() as well.
Noam Rosenthal
Comment 3 2013-10-27 11:55:05 PDT
Comment on attachment 215272 [details] RFC patch View in context: https://bugs.webkit.org/attachment.cgi?id=215272&action=review > Source/WebCore/ChangeLog:11 > + flushCompositingState(), but in some code paths we don't go through it > + and end up calling scheduleLayerFlush() when we shouldn't. What code paths? Seems like this patch works around a problem which we need to understand better. > Source/WebCore/platform/graphics/texmap/coordinated/CompositingCoordinator.cpp:93 > + startedFlushingLayerChanges(); willFlushLayerChanges > Source/WebCore/platform/graphics/texmap/coordinated/CompositingCoordinator.cpp:122 > + finishedFlushingLayerChanges(); didFlushLayerChanges
Sergio Correia (qrwteyrutiyoup)
Comment 4 2013-10-27 12:35:44 PDT
Comment on attachment 215272 [details] RFC patch View in context: https://bugs.webkit.org/attachment.cgi?id=215272&action=review >> Source/WebCore/ChangeLog:11 >> + and end up calling scheduleLayerFlush() when we shouldn't. > > What code paths? Seems like this patch works around a problem which we need to understand better. Here's the backtrace from fast/shapes/shape-inside/shape-inside-rounded-rectangle-004.html on EFL: STDERR: ASSERTION FAILED: !m_flushingLayers STDERR: /home/sergio/projects/webkit/Source/WebCore/rendering/RenderLayerCompositor.cpp(356) : void WebCore::RenderLayerCompositor::scheduleLayerFlush(bool) STDERR: 1 0x7f86e3bfa8b3 WTFCrash STDERR: 2 0x7f86dfe138ae WebCore::RenderLayerCompositor::scheduleLayerFlush(bool) STDERR: 3 0x7f86dfe13812 WebCore::RenderLayerCompositor::notifyFlushRequired(WebCore::GraphicsLayer const*) STDERR: 4 0x7f86dfc04f03 WebCore::CoordinatedGraphicsLayer::notifyFlushRequired() STDERR: 5 0x7f86dfc06b7a WebCore::CoordinatedGraphicsLayer::flushCompositingState(WebCore::FloatRect const&) STDERR: 6 0x7f86dfe13add WebCore::RenderLayerCompositor::flushPendingLayerChanges(bool) STDERR: 7 0x7f86dfa75a81 WebCore::FrameView::flushCompositingStateForThisFrame(WebCore::Frame*) STDERR: 8 0x7f86dfa7e64f WebCore::FrameView::paintContents(WebCore::GraphicsContext*, WebCore::IntRect const&) STDERR: 9 0x7f86dfb21e13 WebCore::ScrollView::paint(WebCore::GraphicsContext*, WebCore::IntRect const&) STDERR: 10 0x7f86dfa7eb45 WebCore::FrameView::paintContentsForSnapshot(WebCore::GraphicsContext*, WebCore::IntRect const&, WebCore::FrameView::SelectionInSnapshot, WebCore::FrameView::CoordinateSpaceForSnapshot) STDERR: 11 0x7f86dc2ab3d5 WebKit::WebPage::scaledSnapshotWithOptions(WebCore::IntRect const&, double, unsigned int) STDERR: 12 0x7f86dc2109d9 WKBundlePageCreateSnapshotWithOptions STDERR: 13 0x7f868d2963e6 WTR::InjectedBundlePage::dump() STDERR: 14 0x7f868d29b85f WTR::InjectedBundlePage::frameDidChangeLocation(OpaqueWKBundleFrame const*, bool) STDERR: 15 0x7f868d296696 WTR::InjectedBundlePage::didFinishLoadForFrame(OpaqueWKBundleFrame const*) STDERR: 16 0x7f868d295043 WTR::InjectedBundlePage::didFinishLoadForFrame(OpaqueWKBundlePage const*, OpaqueWKBundleFrame const*, void const**, void const*) STDERR: 17 0x7f86dc206db2 WebKit::InjectedBundlePageLoaderClient::didFinishLoadForFrame(WebKit::WebPage*, WebKit::WebFrame*, WTF::RefPtr<WebKit::APIObject>&) STDERR: 18 0x7f86dc27ad9c WebKit::WebFrameLoaderClient::dispatchDidFinishLoad() STDERR: 19 0x7f86df96c501 WebCore::FrameLoader::checkLoadCompleteForThisFrame() STDERR: 20 0x7f86df96d039 WebCore::FrameLoader::checkLoadComplete() STDERR: 21 0x7f86df965fc2 WebCore::FrameLoader::checkCompleted() STDERR: 22 0x7f86df965d4e WebCore::FrameLoader::loadDone() STDERR: 23 0x7f86df9e6be8 WebCore::CachedResourceLoader::loadDone(WebCore::CachedResource*) STDERR: 24 0x7f86df99735b WebCore::SubresourceLoader::notifyDone() STDERR: 25 0x7f86df996e8f WebCore::SubresourceLoader::didFinishLoading(double) STDERR: 26 0x7f86df992f8b WebCore::ResourceLoader::didFinishLoading(WebCore::ResourceHandle*, double) STDERR: 27 0x7f86e06471c6 STDERR: 28 0x7f86d89b754a STDERR: 29 0x7f86d89d68bb STDERR: 30 0x7f86d89d68d9 STDERR: 31 0x7f86d882f396 g_main_context_dispatch In https://bugs.webkit.org/show_bug.cgi?id=122016#c0, as in here, we were calling notifyFlushRequired, which would call scheduleLayerFlush. In the prevoius bug we checked whether we were flushing, so and in that case, we wouldn't call notifyFlushRequired. The inconsistency seems to be that inside RenderLayerCompositor::flushPendingLayerChanges() it considers we are in the middle of a flush when we are calling rootLayer->flushCompositingState(visibleRect), however in Coordinated Graphics, who tells us that we are flushing is CompositingCoordinator::flushPendingLayerChanges(), which in this case, doesn't get called -- maybe the problem is here?. This idea in this patch was to indicate that we are in the middle of a flush in flushCompositingState(), to be more consistent with RenderLayerCompositor::flushPendingLayerChanges(). Maybe you have some insights to help here :)
Csaba Osztrogonác
Comment 5 2015-04-01 02:23:12 PDT
It is still valid on EFL (now only EFL uses Coordinated Graphics) and it makes impossible to debug bug143214.
Michael Catanzaro
Comment 6 2017-03-11 10:34:12 PST
Closing this bug because the EFL port has been removed from trunk. If you feel this bug applies to a different upstream WebKit port and was closed in error, please either update the title and reopen the bug, or leave a comment to request this.
Note You need to log in before you can comment on or make changes to this bug.