Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/v8/v8/+/cec3496fdf45562ebf41913ba2f5a5dc3ff60cea (Revert "Reland "[snapshot] Add BuiltinDeserializerAllocator"").

If this is incorrect, please remove the owner and apply the Test-Predator-Wrong-CLs label.

Huh, that was the revert of the CL that caused cfi failures on V8 waterfall. Jakob, could you have a look?

Yeah, that doesn't make any sense, looks like a wrong bisect.

Assigning per V8 issue triage rotation.

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

This testcase contains asm.js that hits the limit on the number of local variables for a single WASM function. This is encountered late, during lazy compilation. We should either ignore the limit for asm.js functions or use the limit as part of asm module validation.

+Michi, since this is an asm.js issue.

I think we should not ignore that limit for asm.js, since some code in V8 is linear in the number of local variables (e.g. for merging SSA environments).
Hence, the asm parser must honor this limit.

CL to fix this: https://crrev.com/c/732660

Re #11: Agreed, something akin to the fix you referenced sounds like the right approach.

ClusterFuzz has detected this issue as fixed in range 48835:48836.

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

Fuzzer: ochang_js_fuzzer
Job Type: linux_cfi_d8
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !thrower.error() in module-compiler.cc
  
Sanitizer: cfi (CFI)

Regressed: https://clusterfuzz.com/revisions?job=linux_cfi_d8&range=48649:48650
Fixed: https://clusterfuzz.com/revisions?job=linux_cfi_d8&range=48835:48836

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

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.

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=6110401040482304.

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

Job Type: linux_cfi_d8
Crash Type: CHECK failure
Crash Address: 
Crash State:
  (location_) != nullptr in handles.h
  
Sanitizer: cfi (CFI)

Regressed: https://clusterfuzz.com/revisions?job=linux_cfi_d8&range=48835:48836

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

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

The bug which is now triggered by the regression test case seems to be the same as 771970. Need to fix that one first.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/bb56b7ecad8486f2ea4a081f701e81ac19323f0e

commit bb56b7ecad8486f2ea4a081f701e81ac19323f0e
Author: Clemens Hammacher <clemensh@chromium.org>
Date: Wed Oct 25 12:45:36 2017

[asm.js] Limit number of local variables

We have an internal limit of 50000 local variables per wasm function.
This limit is checked when decoding the function body. For asm.js, we
skip function body validation, since by construction the code we
generate is correct. This makes us fail unexpectedly when trying to
(lazily) compile an asm.js function with more than 50000 locals.
Hence, check this limit in the asm parser and bail out if it is
exceeded.

R=mstarzinger@chromium.org

Bug:  chromium:775710 
Change-Id: I89d2069e133fb0f84947d477ae1ac5eda85571aa
Reviewed-on: https://chromium-review.googlesource.com/732660
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48929}
[modify] https://crrev.com/bb56b7ecad8486f2ea4a081f701e81ac19323f0e/src/asmjs/asm-parser.cc
[add] https://crrev.com/bb56b7ecad8486f2ea4a081f701e81ac19323f0e/test/mjsunit/regress/wasm/regress-775710.js

This issue has no security impact, but it makes valid asm.js code crash if it contains more than 50k local variables.

@hablich: Is this something we want to merge back?

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

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

I don't think this is blocking. If it is a regression compared to 61, we should merge it back to 62 though. If it is not a regression, let's merge it only to 63.

ClusterFuzz has detected this issue as fixed in range 48906:48907.

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

Job Type: linux_cfi_d8
Crash Type: CHECK failure
Crash Address: 
Crash State:
  (location_) != nullptr in handles.h
  
Sanitizer: cfi (CFI)

Regressed: https://clusterfuzz.com/revisions?job=linux_cfi_d8&range=48835:48836
Fixed: https://clusterfuzz.com/revisions?job=linux_cfi_d8&range=48906:48907

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

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.

Michi, do you know when exactly the asm validator was enabled?
In d8, the flag was flipped to true on July 25, so it should be in 62, right?
In that case, it's a regression (since the code was working in 61 but crashes in 62), so we should merge it back also to 62.

Your change meets the bar and is auto-approved for M63. Please go ahead and merge the CL to branch 3239 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

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

Please merge your change to M63 branch 3239 by 4:00 PM PT, today(Thurday). Thank you.

CL is here, will land as soon as it got LGTM: https://chromium-review.googlesource.com/c/v8/v8/+/739486

ClusterFuzz testcase 5730165572501504 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/f6e4109124089fd70713e08a1e20f96517efabd4

commit f6e4109124089fd70713e08a1e20f96517efabd4
Author: Clemens Hammacher <clemensh@chromium.org>
Date: Fri Oct 27 08:10:58 2017

Merged: [asm.js] Limit number of local variables

We have an internal limit of 50000 local variables per wasm function.
This limit is checked when decoding the function body. For asm.js, we
skip function body validation, since by construction the code we
generate is correct. This makes us fail unexpectedly when trying to
(lazily) compile an asm.js function with more than 50000 locals.
Hence, check this limit in the asm parser and bail out if it is
exceeded.

R=​mstarzinger@chromium.org
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true

Bug:  chromium:775710 
Change-Id: I0d796425b697fdf84307d6daea65bf3f4e8cc28f
Reviewed-on: https://chromium-review.googlesource.com/739486
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/branch-heads/6.3@{#44}
Cr-Branched-From: 094a7c93dcdcd921de3883ba4674b7e1a0feffbe-refs/heads/6.3.292@{#1}
Cr-Branched-From: 18b8fbb528a8021e04a029e06eafee50b918bce0-refs/heads/master@{#48432}
[modify] https://crrev.com/f6e4109124089fd70713e08a1e20f96517efabd4/src/asmjs/asm-parser.cc
[add] https://crrev.com/f6e4109124089fd70713e08a1e20f96517efabd4/test/mjsunit/regress/wasm/regress-775710.js

We are already at ramp-up for M62 and the merge requirements are stricter. Can you please comment on why this is an urgent fix and why is it critical for M62? My recommendation is to target this for M63. 

This is a regression from M61. Code that worked before now reliably crashes in M62. It's not a security risk though, so I am also fine with skipping the merge to M62.

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