This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

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

capn@, could you help diagnose this issue, since you're one of the owner of third_party/swiftshader? 

also cc jbauman@, who has made some changes to swiftshader lately.
Please feel free to re-assign this bug. Thanks!

It appears to throw an std::bad_alloc exception, i.e. it ran out of memory.

We used to have try/catch blocks for this and produce an GL_OUT_OF_MEMORY, but that was removed long ago. I think the reason was that Chromium doesn't use exceptions anywhere, and it caused issues with some tools, but I could be wrong. It's feasible to put this back in.

Antoine, what's the expectation here? I assume all graphics drivers are considered susceptible to out-of-memory crashes and we just restart the GPU process?

If all this is is out-of-memory (address space), then terminating is the right thing to do. We should double-check that we're not trying to allocate a very large buffer though (e.g. buffer for an arbitrary large surface).

The test specifies a 17000x17000 canvas, but I'm only seeing 8192x8192 images being created. The latter is SwiftShader's maximum supported dimensions, so apparently those limits are properly queried and respected. However, the renderbuffer is 4x multisampled so at 32-bit color depth it's a 1 GiB allocation per buffer, so with a 32-bit build it easily runs out of address space. The same test on 64-bit doesn't OOM.

Thanks for confirming that terminating on OOM is the correct behavior.

Should we reduce max dimensions in 32 bits to avoid running into this? Something to consider - it sounds like we're giving the web a primitive to trivially terminate the GPU process from accidental (or malicious) use. It's not the end of the world, but it causes UI jank and general instability.

We increased it from 4096 to 8192 to pass a layout test (https://swiftshader-review.googlesource.com/9988). @sugoi do you recall which test this was? It's not mentioned in the commit message and there's no bug ID.

Assuming that test only runs on 64-bit, I think it's reasonable to reduce the limits back to 4096 for 32-bit builds. That said I don't think it solves much as it's still easy to run out of memory with a handful of calls. Preventing accidental or malicious OOM should probably be prevented at a larger, more global level (e.g. tracking total memory usage, and/or preventing misbehaving content from reloading too often).

ClusterFuzz testcase 5309609912041472 is still reproducing on tip-of-tree build (trunk).

If this testcase was not reproducible locally or unworkable, ignore this notification and we will file another bug soon with hopefully a better and workable testcase.

Otherwise, if this is not intended to be fixed (e.g. this is an intentional crash), please add ClusterFuzz-Ignore label to prevent future bug filing with similar crash stacktrace.

ClusterFuzz has detected this issue as fixed in range 495542:495750.

Detailed report: https://clusterfuzz.com/testcase?key=5309609912041472

Fuzzer: inferno_layout_test_unmodified
Job Type: windows_asan_chrome_no_sandbox
Platform Id: windows

Crash Type: Unknown exception
Crash Address: 0x04f3c14c
Crash State:
  C:\windows\SYSTEM32\KERNELBASE.dll
  sw::allocateZero
  sw::Surface::lockInternal
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_chrome_no_sandbox&range=480776:480824
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_chrome_no_sandbox&range=495542:495750

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5309609912041472

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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