Bug 90848 – [chromium] Assert in decideRenderPassAllocationsForFrame fails when surface is larger than max texture size

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Layout and Rendering

[Hayato Ito]

Started to hit an assertion introduced in http://trac.webkit.org/changeset/122160.

http://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Tests%20%28dbg%29%283%29/builds/7343/steps/interactive_ui_tests/logs/stdio

[ RUN      ] MenuItemViewTestBasic2.SelectItem2
Xlib:  extension "RANDR" missing on display ":9.0".
ASSERTION FAILED: reserved
third_party/WebKit/Source/WebCore/platform/graphics/chromium/LayerRendererChromium.cpp(360) : virtual void WebCore::LayerRendererChromium::decideRenderPassAllocationsForFrame(const WebCore::CCRenderPassList&)
1   0x7f5ded399660
2   0x7f5ded3fc0f6
3   0x7f5ded3fc90b
4   0x7f5ded4222ae
5   0x7f5ded422138
6   0x7f5ded421fa6
7   0x7f5ded3edc2c
8   0x7f5dec11c8f2 WebKit::WebLayerTreeView::composite()
9   0x7f5df0bf54b9 ui::Compositor::Draw(bool)
10  0x7f5df0ce2c1b aura::RootWindow::Draw()
11  0x7f5df0ce98bf
12  0x7f5df0ce9382
13  0x7f5df0ce8c1b
14  0x7f5df5635469
15  0x7f5df5676e8c MessageLoop::RunTask(base::PendingTask const&)
16  0x7f5df5676fa4 MessageLoop::DeferOrRunPendingTask(base::PendingTask const&)
17  0x7f5df56777ad MessageLoop::DoWork()
18  0x7f5df5614ebe
19  0x7f5df561529e
20  0x7f5df5676b51 MessageLoop::RunInternal()
21  0x7f5df5676a08 MessageLoop::RunHandler()
22  0x7f5df56a7db6 base::RunLoop::Run()
23  0x7f5470
24  0x7f5433
25  0x7f55dc
26  0x75bf15
27  0x73120e
28  0x84a898
29  0x847a16
30  0x83c602
31  0x83ce26

[Hayato Ito]

I commented out the assertion in http://trac.webkit.org/changeset/122194 as I and hbono discussed.
Let me watch the result.

[Dana Jansens]

These tests are crashing for me locally still, but the assertion has stopped breaking once I adjust it to account for valid reservation failure. So I think this should resolve the problem.

[Dana Jansens]

Created attachment 151499 [details]
Patch

[Adrienne Walker]

Comment on attachment 151499 [details]
Patch

It's weird to me that calling code needs to know about the conditions in which reserve could fail.  I think you should either move the assert to reserve itself or punt and let bug 90841 take care of this.

[Dana Jansens]

ya.. ok punt it is!

[Dana Jansens]

*** This bug has been marked as a duplicate of bug 90841 ***