Bug 106419 – Assertion Failure in WebCore::RenderLayerCompositor::updateCompositingLayers

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Stephanie Lewis]

Due to http://trac.webkit.org/projects/webkit/changeset/139146

Failing on Mountain Lion and Lion, WK1 and Wk2.  Flaky.

http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK2%20(Tests)/r139161%20(5589)/results.html

+dom/html/level2/html/HTMLDocument11.html
+dom/html/level2/html/HTMLDocument01.html
+dom/html/level2/html/HTMLBodyElement09.html

http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK2%20(Tests)/r139161%20(5589)/dom/html/level2/html/HTMLDocument11-crash-log.txt

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000bbadbeef

VM Regions Near 0xbbadbeef:
--> 
    __TEXT                 000000010ccce000-000000010cccf000 [    4K] r-x/rwx SM=COW  /Volumes/VOLUME/*/WebKit2.framework/WebProcess.app/Contents/MacOS/WebProcess

Application Specific Information:
CRASHING TEST: dom/html/level2/html/HTMLDocument11.html

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.WebCore             	0x00000001104f4f42 WebCore::RenderLayerCompositor::updateCompositingLayers(WebCore::CompositingUpdateType, WebCore::RenderLayer*) + 258 (RenderLayerCompositor.cpp:411)
1   com.apple.WebCore             	0x00000001104f2d5a WebCore::RenderLayerCompositor::updateCompositingLayersTimerFired(WebCore::Timer<WebCore::RenderLayerCompositor>*) + 42 (RenderLayerCompositor.cpp:390)
2   com.apple.WebCore             	0x0000000110504ba3 WebCore::Timer<WebCore::RenderLayerCompositor>::fired() + 115 (Timer.h:106)
3   com.apple.WebCore             	0x0000000110a71006 WebCore::ThreadTimers::sharedTimerFiredInternal() + 294 (ThreadTimers.cpp:119)
4   com.apple.WebCore             	0x0000000110a70d99 WebCore::ThreadTimers::sharedTimerFired() + 25 (ThreadTimers.cpp:94)
5   com.apple.WebCore             	0x00000001107a0383 WebCore::timerFired(__CFRunLoopTimer*, void*) + 67 (SharedTimerMac.mm:167)
6   com.apple.CoreFoundation      	0x00007fff91020da4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
7   com.apple.CoreFoundation      	0x00007fff910208bd __CFRunLoopDoTimer + 557
8   com.apple.CoreFoundation      	0x00007fff91006099 __CFRunLoopRun + 1513
9   com.apple.CoreFoundation      	0x00007fff910056b2 CFRunLoopRunSpecific + 290
10  com.apple.HIToolbox           	0x00007fff927520a4 RunCurrentEventLoopInMode + 209
11  com.apple.HIToolbox           	0x00007fff92751e42 ReceiveNextEventCommon + 356
12  com.apple.HIToolbox           	0x00007fff92751cd3 BlockUntilNextEventMatchingListInMode + 62
13  com.apple.AppKit              	0x00007fff96821613 _DPSNextEvent + 685
14  com.apple.AppKit              	0x00007fff96820ed2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
15  com.apple.AppKit              	0x00007fff96818283 -[NSApplication run] + 517
16  com.apple.WebCore             	0x00000001106cce0c WebCore::RunLoop::run() + 92 (RunLoopMac.mm:37)
17  com.apple.WebKit2             	0x000000010d0bc69f int WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMainDelegate>(WebKit::CommandLine const&) + 815 (ChildProcessMain.h:106)
18  com.apple.WebKit2             	0x000000010d0bc365 WebKit::WebProcessMain(WebKit::CommandLine const&) + 21 (WebProcessMainMac.mm:152)
19  com.apple.WebKit2             	0x000000010cfa9419 WebKitMain(WebKit::CommandLine const&) + 201 (WebKitMain.cpp:56)
20  com.apple.WebKit2             	0x000000010cfa9329 WebKitMain + 153 (WebKitMain.cpp:86)
21  com.apple.WebProcess          	0x000000010ccceda2 main + 274
22  libdyld.dylib                 	0x00007fff981737e1 start + 1

[Stephanie Lewis]

Updated expectations in http://trac.webkit.org/projects/webkit/changeset/139168

[Alexandru Chiculita]

(In reply to comment #20 from 106068)

> Or maybe the compositor update should just bail if layout is dirty (as long as it will happen after the next layout).

Ok. I will replace the assert with a return. I cannot reproduce any of the crashes in local, so I'm trying to build a test to always reproduce the issue. It looks like the common pattern is the java applet that triggers the scheduled compositor update.

[Geoffrey Garen]

I don't think it's right to use expectations / skipping to fix new failures with a known cause. A better approach is to contact the author and/or roll out the offending patch.

[Alexandru Chiculita]

(In reply to comment #3)
> I don't think it's right to use expectations / skipping to fix new failures with a known cause. A better approach is to contact the author and/or roll out the offending patch.

I'm working on it. Will post a patch in a bit.

[Alexandru Chiculita]

Created attachment 181961 [details]
Patch V1

[WebKit Review Bot]

Comment on attachment 181961 [details]
Patch V1

Clearing flags on attachment: 181961

Committed r139229: <http://trac.webkit.org/changeset/139229>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Mikhail Pozdnyakov]

*** Bug 106453 has been marked as a duplicate of this bug. ***