Looks like a lazy compilation issue. I will have a look.

I fixed a related issue on wasm side to avoid the crash (https://chromium-review.googlesource.com/497755). It is now returning and executing the Illegal builtin instead.

But the underlying issue is that the asm validator generates an invalid wasm module.
The problem seems to be that there is no return after the while loop. Not sure if this is valid asm.js code, but I guess not.
=======================================
function __f_61() {
    var __v_81 = 0;
    while((__v_81|0) <= 3)
    return __v_81|0;
  }
=======================================

Assigning to Michi.

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

commit 612471c8bc25171b12ecb6f95a4d010be92c6490
Author: Clemens Hammacher <clemensh@chromium.org>
Date: Mon May 08 14:40:08 2017

[wasm] Assert that lazy compilation does not fail

Since the wasm module is verified before starting execution with lazy
compilation, the compilation of individual functions should not fail
later.
This CL changes the implementation to check this condition earlier
and removes unused error paths.

R=ahaas@chromium.org, mstarzinger@chromium.org
BUG= chromium:719286 

Change-Id: If4bab457a47f214b457b2e2bc8570cba8c8bbcfd
Reviewed-on: https://chromium-review.googlesource.com/497755
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45161}
[modify] https://crrev.com/612471c8bc25171b12ecb6f95a4d010be92c6490/src/wasm/wasm-module.cc
[modify] https://crrev.com/612471c8bc25171b12ecb6f95a4d010be92c6490/src/wasm/wasm-module.h
[modify] https://crrev.com/612471c8bc25171b12ecb6f95a4d010be92c6490/src/wasm/wasm-objects.cc
[modify] https://crrev.com/612471c8bc25171b12ecb6f95a4d010be92c6490/src/wasm/wasm-objects.h

ClusterFuzz has detected this issue as fixed in range 470021:470073.

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

Fuzzer: mbarbella_js_mutation
Job Type: mac_asan_d8
Platform Id: mac

Crash Type: UNKNOWN READ
Crash Address: 0x000000000000
Crash State:
  v8::internal::wasm::LazyCompilationOrchestrator::CompileFunction
  v8::internal::wasm::LazyCompilationOrchestrator::CompileLazy
  v8::internal::WasmCompiledModule::CompileLazy
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_d8&range=469332:469344
Fixed: https://clusterfuzz.com/revisions?job=mac_asan_d8&range=470021:470073

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


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.

This is not fixed yet, just the error message changed. It is now:
#
# Fatal error in ../../src/wasm/wasm-module.cc, line 3231
# Check failed: !thrower.error().
#


The wasm decoder sais:

  +0  local decls count   : 01 = 1
local decls count: 1
  +1  local count         : 01 = 1
  +2  local type          : 7f = 127
{set_env = 0x559a2bff2c30, state = R, reason = initial, control = #1:Start}
wasm-decode 0x914500b07c8...0x914500b07e3 (module+75, 27 bytes) graph building
{set_env = 0x559a2bff2c58, state = R, reason = initial env, control = #11:Merge}
  @3        #i32.const           | B1 |  i@3:i32.const[0]
  @5        #set_local           | B1 | 
  @7        #block               |{set_env = 0x559a2bff2d98, state = R, reason = block:start, control = #11:Merge}
 B1B0 | 
  @9        #loop                |{set_env = 0x559a2bff2df0, state = R, reason = loop:start, control = #26:Merge}
 B1B0L0 | 
  @11       #get_local           | B1B0L0 |  i@11:get_local[0]
  @13       #i32.const           | B1B0L0 |  i@11:get_local[0] i@13:i32.const[3]
  @15       #i32.le_s            | B1B0L0 |  i@15:i32.le_s
  @16       #i32.eqz             | B1B0L0 |  i@16:i32.eqz
  @17       #br_if               | B1B0L0 | 
  @19       #get_local           | B1B0L0 |  i@19:get_local[0]
  @21       #return              | B1B0L0* | 
  @22       #br                  | B1B0L0* | 
  @24       #end                 |{set_env = 0x559a2bff2df0, state = E, reason = loop:end}
 B1B0 | 
  @25       #end                 |{set_env = 0x559a2bff2c58, state = R, reason = block:end, control = #33:IfTrue}
 B1 | 
  @26       #end                 | !expected 1 elements on the stack for fallthru to @3
{set_env = 0x559a2bff2c30, state = U, reason = block:end}
 B1 |  i@3:i32.const[0]?
wasm-error module+98     func+26: expected 1 elements on the stack for fallthru to @3

Result error: expected 1 elements on the stack for fallthru to @3

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

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

Nope, still not fixed.

Thanks! Yes, I'll take a look.

Verified original issue as fixed. Thanks, Michi!

Not sure why the bot doesn't post a comment, the fix is in 0679765dafee0bc17b0f89cc557cd91b936e4d27.

 Issue 721203  has been merged into this issue.

 Issue 721703  has been merged into this issue.

We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.