fast/multicol/span/positioned-child-not-removed-crash.html started to crash on EFL WK2 Bots both Debug and Release after this patch. Could this be related? crash log for WebProcess (pid <unknown>): STDOUT: <empty> STDERR: 1 0x7f6f139e3ab7 STDERR: 2 0x7f6f161484a0 STDERR: 3 0x7f6f12f3813b WebCore::TiledBackingStore::adjustForContentsRect(WebCore::IntRect&) const STDERR: 4 0x7f6f12f38459 WebCore::TiledBackingStore::computeCoverAndKeepRect(WebCore::IntRect const&, WebCore::IntRect&, WebCore::IntRect&) const STDERR: 5 0x7f6f12f37b30 WebCore::TiledBackingStore::createTiles() STDERR: 6 0x7f6f12f36ac0 WebCore::TiledBackingStore::coverWithTilesIfNeeded(WebCore::FloatPoint const&) STDERR: 7 0x7f6f12f3744c WebCore::TiledBackingStore::commitScaleChange() STDERR: 8 0x7f6f12f373e8 WebCore::TiledBackingStore::setContentsScale(float) STDERR: 9 0x7f6f16def1e1 WebCore::CoordinatedGraphicsLayer::createBackingStore() STDERR: 10 0x7f6f16def7de WebCore::CoordinatedGraphicsLayer::updateContentBuffers() STDERR: 11 0x7f6f16deed08 WebCore::CoordinatedGraphicsLayer::flushCompositingStateForThisLayerOnly() STDERR: 12 0x7f6f16dee42a WebCore::CoordinatedGraphicsLayer::flushCompositingState(WebCore::FloatRect const&) STDERR: 13 0x7f6f16dee46b WebCore::CoordinatedGraphicsLayer::flushCompositingState(WebCore::FloatRect const&) STDERR: 14 0x7f6f16dee46b WebCore::CoordinatedGraphicsLayer::flushCompositingState(WebCore::FloatRect const&) STDERR: 15 0x7f6f16dee46b WebCore::CoordinatedGraphicsLayer::flushCompositingState(WebCore::FloatRect const&) STDERR: 16 0x7f6f16dee46b WebCore::CoordinatedGraphicsLayer::flushCompositingState(WebCore::FloatRect const&) STDERR: 17 0x7f6f16dee46b WebCore::CoordinatedGraphicsLayer::flushCompositingState(WebCore::FloatRect const&) STDERR: 18 0x7f6f1311e9d8 WebCore::RenderLayerCompositor::flushPendingLayerChanges(bool) STDERR: 19 0x7f6f12e20719 WebCore::FrameView::flushCompositingStateForThisFrame(WebCore::Frame*) STDERR: 20 0x7f6f12e20a53 WebCore::FrameView::flushCompositingStateIncludingSubframes() STDERR: 21 0x7f6f16df5958 WebKit::LayerTreeCoordinator::flushPendingLayerChanges() STDERR: 22 0x7f6f16df5299 WebKit::LayerTreeCoordinator::forceRepaint() STDERR: 23 0x7f6f16db8a02 WebKit::DrawingAreaImpl::forceRepaint() STDERR: 24 0x7f6f16dd8743 WebKit::WebPage::forceRepaintWithoutCallback() STDERR: 25 0x7f6f16d3e483 WKBundlePageForceRepaint STDERR: 26 0x7f6ec1820d8f WTR::InjectedBundlePage::dump() STDERR: 27 0x7f6ec1825799 WTR::InjectedBundlePage::frameDidChangeLocation(OpaqueWKBundleFrame const*, bool) STDERR: 28 0x7f6ec1821295 WTR::InjectedBundlePage::didFinishLoadForFrame(OpaqueWKBundleFrame const*) STDERR: 29 0x7f6ec181f257 WTR::InjectedBundlePage::didFinishLoadForFrame(OpaqueWKBundlePage const*, OpaqueWKBundleFrame const*, void const**, void const*) STDERR: 30 0x7f6f16d34167 WebKit::InjectedBundlePageLoaderClient::didFinishLoadForFrame(WebKit::WebPage*, WebKit::WebFrame*, WTF::RefPtr<WebKit::APIObject>&) STDERR: 31 0x7f6f16d9ff54 WebKit::WebFrameLoaderClient::dispatchDidFinishLoad() STDERR: LEAK: 1 WebPage STDERR: LEAK: 1 WebFrame STDERR: LEAK: 18 RenderObject STDERR: LEAK: 1 BidiRun STDERR: LEAK: 1 Page STDERR: LEAK: 1 Frame STDERR: LEAK: 501 CachedResource STDERR: LEAK: 49 WebCoreNode
Created attachment 175359 [details] Patch
Comment on attachment 175359 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=175359&action=review > Source/WebCore/platform/graphics/TiledBackingStore.cpp:367 > + ASSERT(!rect.width()); After taking time to think whether it is always true, I think adjustForContentsRect() does not avoid all possibilities physically. So I posted Bug 102908. After Bug 102908, the ASSERT is always true.
Created attachment 175393 [details] Patch
(In reply to comment #2) > (From update of attachment 175359 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=175359&action=review > > > Source/WebCore/platform/graphics/TiledBackingStore.cpp:367 > > + ASSERT(!rect.width()); > > After taking time to think whether it is always true, I think adjustForContentsRect() does not avoid all possibilities physically. > > So I posted Bug 102908. > After Bug 102908, the ASSERT is always true. In the second patch, assertions in TiledBackingStore moved to Bug 102908.
Comment on attachment 175393 [details] Patch Is this ok to commit, or do we need to wait for the other one
(In reply to comment #5) > (From update of attachment 175393 [details]) > Is this ok to commit, or do we need to wait for the other one Actually, we can commit. This bug does not depend on Bug 102908 physically.
Comment on attachment 175393 [details] Patch Clearing flags on attachment: 175393 Committed r135434: <http://trac.webkit.org/changeset/135434>
All reviewed patches have been landed. Closing bug.