Bug 10249 – Temporarily disable tests that are causing kernel panics

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Alexey Proskuryakov]

My MBP recently had a kernel panic when running layout tests in pixel mode. Bug 9830 comment 2 suggests that this is not an isolated issue.

The panic log had ATI drivers in the backtrace; my unfounded suspicion is on CI filters (just because I recently read somewhere that CoreImage often causes panics with ATI drivers).

[David Kilzer (:ddkilzer)]

Alexey, did your screen saver come on while the pixel tests were running?  I've had my PowerBook G4 crash the kernel twice when running pixel tests with the "Flurry" screen saver running.  (Both times I left the tests running after heading to work for the day, then returned to find the PowerBook had locked up.  Both times Crash Reporter or whatever handles kernel crashes was able to send some info to Apple about the crash.)

[Darin Adler]

Yes, those of us at Apple are aware that we get kernel panics when running layout tests.

And yes, we do think the CoreImage filters are the cause.

But this is not a bug in WebKit. A misbehaving user program should not be able to cause a kernel panic -- it has to be a bug in a driver or the kernel.

Brady Eidson reported this to the appropriate teams at Apple and they're investigating. But we should not keep a bug open in Bugzilla about this unless we think there's something the WebKit team can do about this, and I think there's not.

[Alexey Proskuryakov]

(In reply to comment #2)
> But we should not keep a bug open in Bugzilla about this unless
> we think there's something the WebKit team can do about this, and I think
> there's not.

My idea was that we could probably at least identify and disable the offending tests in the time being.

[Darin Adler]

(In reply to comment #3)
> My idea was that we could probably at least identify and disable the offending
> tests in the time being.

That seems like a good idea. It's OK if you want to reopen the bug especially if you change the title to make it clear that's what we're trying to do.

I thought it was the code in ImageDiff itself that was causing the kernel panics, not any code that runs inside WebKit, so any pixel failure can trigger the panic. If that's the case, it might help to add a "safe mode" or "slow mode" to DumpRenderTree that doesn't invoke ImageDiff or uses the software renderer to compute the difference image.

Created attachment 12360 [details]
Make ImageDiff not use CoreImage

This patch makes ImageDiff not cause kernel panics on at least one machine where it used to (2GHz MacBook Pro).

The results difference images produced with this patch are equivalent but not identical to current ones: the CoreImage version amplified small differences. However the percentage of different pixels reported should be the same, and any difference, as small as one unit in on component, show in the difference image.

[Dave Hyatt]

Comment on attachment 12360 [details]
Make ImageDiff not use CoreImage

r=me

[Mark Rowe (bdash)]

Landed in r18789.