Able to reproduce the crash on win10 chrome version 55.0.2883.87 and canary 57.0.2985.0

Crash ID : fc2baf6580000000

Able to reproduce the issue on Windows 10 and Ubuntu 14.04 using chrome reported version #55.0.2883.87 and latest canary #57.0.2986.0 .
This issue is not reproducible on Mac OS.

Bisect Information:
=====================
Good build: 41.0.2268.0  Revision(310078)

Bad Build : 41.0.2270.0  Revision(310460)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/e12366500f67a1f5a2ff4b6ac8b93d1f4b036f89..3a5e72899629e0c8d254109707e747742686fbca

From the above change log suspecting below change

Review url: https://codereview.chromium.org/837773003

junov@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks...!!

There is a massive memory leak causing an OOM crash.  The bisect in comment #2 points to a very old revision (that was perhaps buggy, but was probably fixed since then).  There is a more recent regression because 54.0.2840.100 does not repro the issue.

My mistake, the regression range in #2 is correct.

The problem has to do with the use of display lists.  The benchmark is calling canvas command that modifiy state in a tight loop without ever drawing anything and without ever presenting the canvas to the screen as a result, we end-up recording a very long list of command without ever flushing them. We should probably just set a maximum size for the recording and make the canvas fall back into immediate mode when the size is exceeded.

We already have a similar fallback heuristic that is based on pixels drawn, but in this case there is no drawing, only state changes, so this use case falls through the cracks.

Downgrading the priority since the OOM crash is based on a use case that does not have a practical purpose (pushing millions of canvas API calls without ever drawing anything).