RESOLVED FIXED 92660
[chromium] Layout tests svg-filters.html and alpha.html are crashing intermittently
https://bugs.webkit.org/show_bug.cgi?id=92660
Summary [chromium] Layout tests svg-filters.html and alpha.html are crashing intermit...
Stephen White
Reported 2012-07-30 10:52:54 PDT
platform/chromium/compositing/accelerated-drawing/svg-filters.html platform/chromium/compositing/accelerated-drawing/alpha.html are crashing intermittently on all platforms due to an assert. This looks to have been exposed by: http://trac.webkit.org/changeset/123987 which passes through the acceleratePainting flag to settings. Sample Linux crash stack: crash log for DumpRenderTree (pid 6766): STDOUT: <empty> STDERR: [6766:6766:915311230:ERROR:gles2_cmd_decoder.cc(5109)] GL ERROR :GL_INVALID_OPERATION : glFramebufferTexture2D: unknown texture STDERR: base::debug::StackTrace::StackTrace() [0x82d82a8] STDERR: base::(anonymous namespace)::StackDumpSignalHandler() [0x82c17bd] STDERR: 0xb773d400 STDERR: WebCore::FrameBufferSkPictureCanvasLayerTextureUpdater::updateTextureRect() [0x88caa79] STDERR: WebCore::FrameBufferSkPictureCanvasLayerTextureUpdater::Texture::updateRect() [0x88cae62] STDERR: WebCore::(anonymous namespace)::UnthrottledTextureUploader::uploadTexture() [0x89088d4] STDERR: WebCore::CCTextureUpdater::update() [0x88fe628] STDERR: WebCore::CCSingleThreadProxy::doCommit() [0x88fcf1d] STDERR: WebCore::CCSingleThreadProxy::commitAndComposite() [0x88fcfcc] STDERR: WebCore::CCSingleThreadProxy::compositeAndReadback() [0x88fd48f] STDERR: WebCore::CCLayerTreeHost::compositeAndReadback() [0x88db3d4] STDERR: WebKit::WebLayerTreeView::compositeAndReadback() [0x8104c1b] STDERR: WebKit::WebViewImpl::doPixelReadbackToCanvas() [0x80c61a8] STDERR: WebKit::WebViewImpl::paint() [0x80c65aa] STDERR: WebViewHost::paintRect() [0x8089750] STDERR: WebViewHost::paintInvalidatedRegion() [0x80898b1] STDERR: TestShell::dump() [0x80852d6] STDERR: TestShell::testFinished() [0x80858c9] STDERR: LayoutTestController::WorkQueue::processWorkSoon() [0x8066a65] STDERR: WebViewHost::locationChangeDone() [0x808a0e8] STDERR: WebKit::FrameLoaderClientImpl::dispatchDidFinishLoad() [0x80ef741] STDERR: WebCore::FrameLoader::checkLoadCompleteForThisFrame() [0x8b68dfd] STDERR: WebCore::FrameLoader::checkLoadComplete() [0x8b68fd9] STDERR: WebCore::DocumentLoader::finishedLoading() [0x8b51822] STDERR: WebCore::MainResourceLoader::didFinishLoading() [0x8b79399] STDERR: WebCore::ResourceLoader::didFinishLoading() [0x8b8e166] STDERR: WebCore::ResourceHandleInternal::didFinishLoading() [0x9817dab] STDERR: webkit_glue::WebURLLoaderImpl::Context::OnCompletedRequest() [0x92f872e] STDERR: (anonymous namespace)::RequestProxy::NotifyCompletedRequest() [0x93983f6] STDERR: base::internal::Invoker<>::Run() [0x939860b] STDERR: MessageLoop::RunTask() [0x82b5080] STDERR: MessageLoop::DeferOrRunPendingTask() [0x82b5722] STDERR: MessageLoop::DoWork() [0x82b5a81] STDERR: base::MessagePumpGlib::HandleDispatch() [0x82d2018] STDERR: (anonymous namespace)::WorkSourceDispatch() [0x82d2057] STDERR: 0xb75325e5 STDERR: 0xb75362d8 STDERR: 0xb75364b8 STDERR: base::MessagePumpGlib::RunWithDispatcher() [0x82d24e9] STDERR: base::MessagePumpGlib::Run() [0x82d207e] STDERR: MessageLoop::RunInternal() [0x82b043e] STDERR: base::RunLoop::Run() [0x82c1a69] STDERR: MessageLoop::Run() [0x82af60e] STDERR: webkit_support::RunMessageLoop() [0x81cbff7] STDERR: TestShell::waitTestFinished() [0x8085999] STDERR: TestShell::runFileTest() [0x8083f9f] STDERR: runTest() [0x805d3f3] STDERR: main [0x805d9d3] STDERR: 0xb6a3abd6 STDERR: 0x805c561
Attachments
proposed patch (3.09 KB, patch)
2012-08-27 15:02 PDT, Alok Priyadarshi
no flags
proposed patch (2.61 KB, patch)
2012-08-27 15:13 PDT, Alok Priyadarshi
webkit.review.bot: commit-queue-
proposed patch (2.56 KB, patch)
2012-08-28 09:27 PDT, Alok Priyadarshi
no flags
Adjusting TestExpectations (1.51 KB, patch)
2012-09-06 14:46 PDT, Alok Priyadarshi
no flags
Alok Priyadarshi
Comment 1 2012-08-27 14:19:06 PDT
Accelerated painting used the compositor context to create and upload the tile textures. Now it seems we use two contexts - one that creates the texture and another to upload it. Although the texture is shared by the two contexts, it is not immediately available after creation to the context that uploads it. Flushing the context that creates it fixes the problem.
Alok Priyadarshi
Comment 2 2012-08-27 15:02:59 PDT
Created attachment 160818 [details] proposed patch
Alok Priyadarshi
Comment 3 2012-08-27 15:13:42 PDT
Created attachment 160822 [details] proposed patch sync'd with TOT.
Dana Jansens
Comment 4 2012-08-27 15:13:59 PDT
The Framebuffer texture updater isn't actually used unless enabled by command-line flags anywhere. At a minimum you will need to do something on other code paths such as BitmapCanvasLayerTextureUpdater (the default updater). But presumably you want to flush the sharedContext used for filters, not the context being used for upload, and we should do this once before any uploading takes place? Maybe CCTextureUpdateController?
Dana Jansens
Comment 5 2012-08-27 15:16:01 PDT
Oh I may be thinking backwards, the texture is created by our resource provider, but we're uploading using ganesh? Too used to the other way around. If so then ignore my last comment.
Alok Priyadarshi
Comment 6 2012-08-27 15:22:14 PDT
Right. This class is exclusively used by accelerated-painting path. AFAIK BitmapCanvasLayerTextureUpdater is not affected by using two contexts. In fact I am not even aware when we switched to using two contexts. I am not flushing the context that uploads. I am flushing the context that creates the textures. We could add a flush here: http://trac.webkit.org/browser/trunk/Source/WebCore/platform/graphics/chromium/cc/CCResourceProvider.cpp#L124 (right after the texture is created), but that would affect other texture-updaters as well - even the ones that do not need it.
Dana Jansens
Comment 7 2012-08-27 15:27:42 PDT
Yeh this seems legit as presented, sorry for my misunderstanding!
WebKit Review Bot
Comment 8 2012-08-27 15:38:49 PDT
Comment on attachment 160822 [details] proposed patch Attachment 160822 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13648036
Peter Beverloo (cr-android ews)
Comment 9 2012-08-27 17:18:13 PDT
Comment on attachment 160822 [details] proposed patch Attachment 160822 [details] did not pass cr-android-ews (chromium-android): Output: http://queues.webkit.org/results/13635103
Alok Priyadarshi
Comment 10 2012-08-28 09:27:08 PDT
Created attachment 160998 [details] proposed patch sync'd again with TOT.
Alok Priyadarshi
Comment 11 2012-08-28 15:35:01 PDT
james: can you review it?
Alok Priyadarshi
Comment 12 2012-08-29 17:35:43 PDT
ping!
WebKit Review Bot
Comment 13 2012-08-31 11:24:03 PDT
Comment on attachment 160998 [details] proposed patch Clearing flags on attachment: 160998 Committed r127294: <http://trac.webkit.org/changeset/127294>
WebKit Review Bot
Comment 14 2012-08-31 11:24:07 PDT
All reviewed patches have been landed. Closing bug.
Alok Priyadarshi
Comment 15 2012-09-06 14:46:42 PDT
Created attachment 162592 [details] Adjusting TestExpectations Adjusting test expectations after watching test bots and flakiness dashboard. It seems the earlier patch indeed fixed the problem.
Alok Priyadarshi
Comment 16 2012-09-06 14:48:01 PDT
Stephen: Could you approve the TestExpectations patch. Thanks.
James Robinson
Comment 17 2012-09-06 14:48:13 PDT
Don't attach new patches to closed bugs - open a new bug for new patches if you want a review. For this, I'd just commit it.
Note You need to log in before you can comment on or make changes to this bug.