stack trace is not very helpful... mbarbella@, any advice on how to proceed from here?

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

The minimized repro creates a canvas and sets its width and height to 17000 and then gets the webgl context. That doesn't sound like it should cause any memory corruption? Adding Blink>Canvas (even though it says non-webgl) and Blink>WebGL for both teams to be able to view the bug.

I'm pretty sure it's just running out of memory and crashing due to that. I get a crash of the gpu process when I try to run the test case locally:

[17618:17618:0711/152332.869863:ERROR:gles2_cmd_decoder.cc(8530)] [.Offscreen-For-WebGL-0x3411813aae00]GL ERROR :GL_OUT_OF_MEMORY : glRenderbufferStorageMultisample: dimensions too large

Actually it may not crash, it may just fail to run. But I wouldn't be surprised if the crash was due to OOM. I'll try to repro locally.

A friendly reminder that M61 branch is coming soon on 07/20! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix ASAP to trunk. This way we branch M61 from a high quality trunk. Thank you.

The stack trace has evolved in recent revisions.  Now, it seem to be hitting The NOTREACHED() in GLSurface::SetRelyOnImplicitSync, which was added in this CL: https://chromium-review.googlesource.com/c/562178/

@dcastagna: PTAL

 crbug.com/740630  is keeping track of the NOTREACHED in GLSurface::SetRelyOnImplicitSync.

I'm not sure how that is related to this bug though. https://chromium-review.googlesource.com/c/562178/ was merged yesterday and this bug was opened 3 days ago.

The relation is that the NOTREACHED() in GLSurface::SetRelyOnImplicitSync is now the site of the crash. It is probably masking the original crash site because it happens earlier, but we can't know for sure until the NOTREACHED() is fixed.

Marking this as blocked on 740630

junov: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

URGENT - PTAL.
Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the M61 branch #3163 ASAP to have enough baking time in Beta before Stable promotion. Thank you!

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label.

I can't repro this bug, not even with the archived asan build that is attached to the bug report, using the exact same command line options. I am going to try a speculative fix...

My idea for a speculative fix was to clamp the WebGL DrawingBuffer's size to MAX_TEXTURE_SIZE, but it looks like the implementation is already doing this. So that is not the problem. 

Also, the layout test that this failure was generated from is currently expected to crash on Windows bots due to an out of memory failure.  The canvas backing requires 1GB of contiguous memory, which is likely to fail in 32-bit builds.  Due to the lack of actionable info in the report, I can't tell whether this asan failure is just an alternate manifestation of the OOM crash that is expected.

* "Unknown exception"
* Unusable stack trace
* Can't repro.

The only bit of usable info I have to go on is the reduced test case.  But it's not enbough. I don't know what to do with this bug.

Closing due to lack of actionable data.  There is no evidence that this crash is different from the expected OOM crash for the same test case on non-asan 32-bit builds.

ClusterFuzz testcase 6320959819874304 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 495551:495853.

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

Fuzzer: inferno_layout_test_unmodified
Job Type: windows_asan_chrome
Platform Id: windows

Crash Type: Unknown exception
Crash Address: 0x04dec70c
Crash State:
  RaiseException
  _asan_wrap__except_handler4
  _asan_wrap__except_handler4
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_chrome&range=480776:480854
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_chrome&range=495551:495853

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

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