This causes a crash for me as well on Linux on 56.0.2900.0 (ish; I'm on my own branch). It only takes a few seconds. It seems to use 300-400 MB of system memory and slows my desktop framerate significantly while running.

I get an out of memory error:

[38654:38654:1025/154225:FATAL:memory_linux.cc(35)] Out of memory.
#0 0x7fcd0804b25e base::debug::StackTrace::StackTrace()
#1 0x7fcd0806e5cb logging::LogMessage::~LogMessage()
#2 0x7fcd0809fa91 base::(anonymous namespace)::OnNoMemory()
#3 0x7fcd0811aef9 ShimMalloc
#4 0x7fccf149c699 <unknown>

Received signal 6
#0 0x7fcd0804adf7 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#1 0x7fcd081a8330 <unknown>
#2 0x7fccfeb94c37 gsignal
#3 0x7fccfeb98028 abort
#4 0x7fcd080491c2 base::debug::BreakDebugger()
#5 0x7fcd0806e88a logging::LogMessage::~LogMessage()
#6 0x7fcd0809fa91 base::(anonymous namespace)::OnNoMemory()
#7 0x7fcd0811aef9 ShimMalloc
#8 0x7fccf149c699 <unknown>
  r8: ffff82a7f1069ce8  r9: ffff82a7f1069cd8 r10: 0000000000000008 r11: 0000000000000202
 r12: 0000000005728e57 r13: 000002a4646f4858 r14: 00007ffc73cfd198 r15: 00007ffc73cfd188
  di: 00000000000096fe  si: 00000000000096fe  bp: 0000000000000001  bx: 0000000000000000
  dx: 0000000000000006  ax: 0000000000000000  cx: ffffffffffffffff  sp: 00007ffc73cfcbe8
  ip: 00007fccfeb94c37 efl: 0000000000000202 cgf: 000c000000000033 erf: 0000000000000000
 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]

I wonder if there's a recently-introduced resource leak in the communication of the DrawingBuffer's texture to the compositor.

The glGenSyncTokenCHROMIUM warning/error is happening because the GPU process is crashing, and some code in the renderer process isn't responding well to that.

Actually, I'm able to reproduce it on stable 54.0.2840.71 as well.

Stable Windows 48.0.2564.109 (64-bit) reproduces the same issue, except the glGenSyncTokenCHROMIUM warning is missing.

Thanks for confirming my suspicion that the GPU process is crashing. When the page crashes, I see that the memory usage of the GPU process immediately drops to 0, but it retains a PID, which lead me to believe it was still alive in some sense.

Do you need any more info to help get this assigned?

Another version of the test case which uses requestAnimationFrame instead of setInterval would be helpful. We are swamped and haven't had time to investigate this yet, but the fact that this animates on a fixed time interval, rather than allowing the browser to provide feedback if it can't keep up, is a red flag.

Xida, do you think you could take a look at this? I have a feeling it might be related to recent work in DrawingBuffer, and might indicate a leak of GPU resources.

Investigating.

Some initial investigation:

I ran the test page on Linux ToT, it crashes in 5 seconds. I looked at the task manager and GPU process uses 60MB, and the renderer process uses 18MB, it should not be OOM crash.

Ken, Kai, could either one of you confirm the above behavior?

Then I tried to see if we have a good build on this. I went back to chrome 49.0.2574.0 and it has the same behavior (crashes in about 5 seconds).

I will have a debug build and attach stacktrace to see what's going on.

It doesn't crash when I attach a debugger to it. The GPU process is at ~700 for 10 mins now and there is no crash...

A little bit more updates: I observed the console output on both ToT and chrome 49, seem to have the same behavior, both canvases size were set to 0*0 when the time it crashes, when we refresh the page, gl instance is null.

OK, I think I know what's going on.

When running the html file, the function resizeContainers gets triggered after 1000ms, when running this function, somewhere there is a webgl context lost event (indicated by the console output), and then the gl.drawingBufferWidth and gl.drawingBuffer height becomes 0. However, the animate() function just keeps running, and gl is null already, then it crashes.

When refresh page, the code path goes into here:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp?sq=package:chromium&rcl=1479284732&l=656

and the gl context never successfully created.

Ken, does the above analysis make sense? This doesn't seem to have to do with any recent change as I can repro it with chrome 49. I think the reason is that the webgl context lost event is not handled properly in the script.

Thanks Xida for confirming that the test fails with Chrome 49. If the bug is that old it's not related to recent DrawingBuffer changes.

I suspect that we're leaking textures presented to the compositor because this test case resizes the canvas on a fixed time interval rather than using requestAnimationFrame. We should really figure out why the textures aren't being reclaimed promptly.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot