152009 2015-12-08 12:33:56 -0800 fast/canvas/canvas-too-large-to-draw.html failing on El Capitan Debug 2016-04-28 14:49:36 -0700 1 1 1 Unclassified WebKit Canvas WebKit Nightly Build Mac OS X 10.11 RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=151825 InRadar P2 Normal --- 1 ryanhaddad webkit-unassigned ap bfulgham dino sabouhallawa simon.fraser webkit-bug-importer oldest_to_newest 1147427 0 ryanhaddad 2015-12-08 12:33:56 -0800 fast/canvas/canvas-too-large-to-draw.html failing on El Capitan Debug Run: <https://build.webkit.org/builders/Apple%20El%20Capitan%20Debug%20WK2%20%28Tests%29/builds/1543> Results: <https://build.webkit.org/results/Apple%20El%20Capitan%20Debug%20WK2%20(Tests)/r193764%20(1543)/results.html> --- /Volumes/Data/slave/elcapitan-debug-tests-wk2/build/layout-test-results/fast/canvas/canvas-too-large-to-draw-expected.txt +++ /Volumes/Data/slave/elcapitan-debug-tests-wk2/build/layout-test-results/fast/canvas/canvas-too-large-to-draw-actual.txt @@ -1,2 +1,2 @@ -CONSOLE MESSAGE: line 36: Canvas area exceeds the maximum limit (width * height > 268435456). +CONSOLE MESSAGE: line 31: TypeError: null is not an object (evaluating 'ctx.fillStyle = "lime"') 1147435 1 ryanhaddad 2015-12-08 12:38:06 -0800 Marked as flaky on ElCapitan Debug in r193770 1147507 2 bfulgham 2015-12-08 16:01:11 -0800 This is related to my change. For some reason, the active pixel count is reaching our maximum threshold while running tests on these machines. This indicates that either the canvas buffers are getting held onto longer than we expect, or the bookkeeping code is not properly decrementing the counts when run under the test system. Skipping for now is a good approach, and I'll look into the underlying issue. 1147522 3 ryanhaddad 2015-12-08 16:23:46 -0800 Changed expectation to skip in <https://trac.webkit.org/r193794> 1147535 4 ryanhaddad 2015-12-08 16:40:47 -0800 Skipped on Win with <https://trac.webkit.org/r193797> 1148045 5 ap 2015-12-09 19:33:06 -0800 Why not roll out the change until this issue can be addressed? The regression seems pretty bad. 1148207 6 bfulgham 2015-12-10 09:07:03 -0800 (In reply to comment #5) > Why not roll out the change until this issue can be addressed? The > regression seems pretty bad. I disagree. I think the problem corrected by this patch is far more severe than this test failing. I'll try to get this test fixed in the next day or two. 1148229 7 webkit-bug-importer 2015-12-10 09:42:04 -0800 <rdar://problem/23841377> 1148231 8 bfulgham 2015-12-10 09:52:29 -0800 (In reply to comment #6) > (In reply to comment #5) > > Why not roll out the change until this issue can be addressed? The > > regression seems pretty bad. > > I disagree. I think the problem corrected by this patch is far more severe > than this test failing. > > I'll try to get this test fixed in the next day or two. I just talked with Alexey about the history of the original "canvas-too-large-to-draw" test, and I now agree that it is very important to keep this running. Therefore, I'll roll my patch out and re-enable this test. 1188396 9 bfulgham 2016-04-28 14:49:36 -0700 Note that my fix (which made this test flaky) was re-landed: Revised patch (to satisfy the test case) re-landed: Committed r194290: <http://trac.webkit.org/changeset/194290>