Find it did not provide any possible suspect. From the regression range assigning to the concern owner.
https://chromium.googlesource.com/v8/v8/+log/e32535af5a5f4776a58ef434ea77d56528ded427..788e74f5dcde7c6b83ae7bbbc5e88f99361a587d?pretty=fuller

@marja -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

The relevant file is: mutant13791_redundancy2.js

Minified even more by hand:

function outer() {
    "use asm";
    function inner() {
      switch (1) {
        case 0:
        break foo;
      }
    }
}

outer();

So apparently, now that we parse inner lazily, that fails.

A wild guess: the error in the inner function is not early (even though it should be according to the spec), and AsmJs::CompileAsmViaWasm doesn't take into account that we might fail on something that we didn't fail before when lazy parsing?

Nah, dunno if that guess makes any sense.

However, looks like an asmjs problem to me, so assigning to bradnelson@.

Also, no asan needed for this, this is enough:

out/Debug/d8 --ignition-staging ../foo.js

Investigating...

This fixs the proximate failure (for the --validate-asm case):
https://codereview.chromium.org/2614563002

However, --ignition-staging then fails due to touching garbage scopes.

Marja, I'm guess the ParseAndAnalyze I'm running leaves behind something that then throws off a reparse. Alternatively, letting through the original parsing exception (done in a zone), also seems to have problems.
Any recommendations about how to clear things up properly when parsing fails?
Thanks!

Hmm, I don't have educated guesses about what's happening there (ie why you're having problems). After getting rid of the ParseInfo and the Zone, starting a fresh parse shouldn't be a problem from Parser point of view... ofc the Isolate has the pending exception which might need to be cleared, but idk what else could affect it.

Fix out for review:
https://codereview.chromium.org/2614563002/

ClusterFuzz has detected this issue as fixed in range 42439:42440.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4803404494012416

Fuzzer: decoder_langfuzz
Job Type: linux_asan_d8_ignition_dbg
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !info->isolate()->has_pending_exception() in asm-js.cc
  
Sanitizer: address (ASAN)

Regressed: V8: 41672:41673
Fixed: V8: 42439:42440

Minimized Testcase (9.86 Kb): https://cluster-fuzz.appspot.com/download/AMIfv94JDTO-0TKBfwE7XqgPsosAY-1XdeLCIYI1hWBr5nLuPuWXggOh6aLgKYINw0Ye2ekShPKGZJflewcK6OhOiAU-qdXVqM3f4VGlLF3Di9Wp7bZKtAjaW44Ohx2CXI36Jrhx_0N_fEva28vXyEaIMx6psWj6bw?testcase_id=4803404494012416

See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

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

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

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