Can you provide us with the server crash id? (Available from chrome://crashes)

No, I can't. Chromium reports that crash reports are disable, even after I go to settings and enable them. What't the problem? I think I provided enough information to reproduce the issue.

I was able to repro:

#
# Fatal error in ../v8/src/wasm/wasm-module.cc, line 2063
# Check failed: table->max_size >= table->size (0 vs. 748).
#

==== C stack trace ===============================

    /usr/local/google/home/binji/dev/chromium/src/out/./libv8_libbase.so(+0x15913) [0x7f3905410913]
    /usr/local/google/home/binji/dev/chromium/src/out/./libv8_libbase.so(V8_Fatal+0xdd) [0x7f390540be1d]
    /usr/local/google/home/binji/dev/chromium/src/out/./libv8.so(+0xa57f80) [0x7f3910844f80]
    /usr/local/google/home/binji/dev/chromium/src/out/./libv8.so(v8::internal::wasm::WasmModule::CompileFunctions(v8::internal::Isolate*, v8::internal::wasm::ErrorThrower*) const+0x13d) [0x7f3910841ded]
    /usr/local/google/home/binji/dev/chromium/src/out/./libv8.so(v8::internal::wasm::CreateModuleObjectFromBytes(v8::internal::Isolate*, unsigned char const*, unsigned char const*, v8::internal::wasm::ErrorThrower*, v8::internal::wasm::ModuleOrigin, v8::internal::Handle<v8::internal::Script>, unsigned char const*, unsigned char const*)+0xc1) [0x7f3910847da1]
    /usr/local/google/home/binji/dev/chromium/src/out/./libv8.so(+0xa485ff) [0x7f39108355ff]
    /usr/local/google/home/binji/dev/chromium/src/out/./libv8.so(+0x17891d) [0x7f390ff6591d]
    /usr/local/google/home/binji/dev/chromium/src/out/./libv8.so(+0x238b8b) [0x7f3910025b8b]
    /usr/local/google/home/binji/dev/chromium/src/out/./libv8.so(+0x237978) [0x7f3910024978]
    /usr/local/google/home/binji/dev/chromium/src/out/./libv8.so(+0x237561) [0x7f3910024561]
    [0x500fa7043a7]
Received signal 4 ILL_ILLOPN 7f390540f592

Can you provide an example binary that fails?
The check that binji mentioned above no longer exists.

However, I did notice a bug in allocating tables that is fixed here:
https://codereview.chromium.org/2433313002

I updated my WASM backend and now generated wasm files pass ml_proto checks and run in Firefox Nightly. However, Chromium still crashes. I published my example here: http://teavm.org/live-examples/jbox2d-benchmark/teavm-wasm-12.html

The quickfix for you before the Chromium change lands is to add a maximum table size which is greater than or equal to the initial table size.

The problem that I don't specify maximum table size in my latest binary, `resizable_limits` allow it by specifying 0 for `flags` field.

Right. If you specify the maximum size, everything should work with Chrome. I have a fix in V8 that should land soon, and that takes about half a day to roll into Chrome.

With this workaround my example still does not work. Chromium prints the following to the console:

Received signal 11 SEGV_MAPERR 000000000000
#0 0x5604be3156f7 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#1 0x7f31c1a11a00 <unknown>
#2 0x5604bd75f491 std::_Rb_tree<>::find()
#3 0x5604bd75f41b v8::internal::wasm::SignatureMap::Find()
#4 0x5604bd76f1e1 v8::internal::wasm::BuildFunctionTable()
#5 0x5604bd76ce8e v8::internal::wasm::WasmModule::CompileFunctions()
#6 0x5604bd772155 v8::internal::wasm::CreateModuleObjectFromBytes()
#7 0x5604bd763a0c v8::(anonymous namespace)::WebAssemblyCompile()
#8 0x5604bd0da8f4 v8::internal::FunctionCallbackArguments::Call()
#9 0x5604bd15296d v8::internal::(anonymous namespace)::HandleApiCallHelper<>()
#10 0x5604bd151e75 v8::internal::Builtin_Impl_HandleApiCall()
#11 0x38a4860843a7 <unknown>
  r8: 0000199aef2d0158  r9: 0000000000000000 r10: 0000000000000003 r11: 0000000000000001
 r12: 0000000000000001 r13: 0000199aef0290c0 r14: 0000000000000a38 r15: 0000199aef2d0148
  di: 0000199aef2d0158  si: 00007ffcfe4427e8  bp: 0000199aef2d0128  bx: 0000199aef2d0148
  dx: 000002a400000000  ax: 0000199aef2c2c00  cx: 0000199aef2c2c00  sp: 00007ffcfe4427b0
  ip: 00005604bd75f491 efl: 0000000000010206 cgf: 002b000000000033 erf: 0000000000000004
 trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]

Deleted: classes.wasm 402 KB

classes.wasm 402 KB Download

Thanks for attaching your example! That uncovered another bug, which I am fixing now. 

I think you'll have to wait for the Chrome roll for these two bugs to be fixed.

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

commit 85cb43cbb85cabfb9e326ae4046b080c5c856be2
Author: titzer <titzer@chromium.org>
Date: Thu Oct 20 11:26:14 2016

[wasm] Fix canonicalization bug for function signatures in CallIndirect.

R=ahaas@chromium.org
BUG= chromium:654231 

Review-Url: https://chromiumcodereview.appspot.com/2439613003
Cr-Commit-Position: refs/heads/master@{#40463}

[modify] https://crrev.com/85cb43cbb85cabfb9e326ae4046b080c5c856be2/src/compiler/wasm-compiler.cc
[modify] https://crrev.com/85cb43cbb85cabfb9e326ae4046b080c5c856be2/test/cctest/wasm/test-run-wasm.cc

I verified that the last change allows the module to compile, but didn't go so far as to patch into Chromium and verify the example runs. Please open another bug if it fails with the next canary.

Confirmed. Now Chromium tab does not crash, thanks. However, I still can't run my application, Chromium reports:

at method$38org_gjbox2d_gpooling_gnormal_gMutableStack_V11_extendStackI (<WASM>[79]+231)
    at method$42org_gjbox2d_gpooling_gnormal_gDefaultWorldPool_V8__hinit_iII (<WASM>[89]+531)
    at method$40org_gteavm_gsamples_gbenchmark_gshared_gScene_V8__hinit_i (<WASM>[22]+285)
    at method$54org_gteavm_gsamples_gbenchmark_gteavm_gWasmBenchmarkStarter_V10__hclinit_i (<WASM>[182]+62)
    at clinit$org_gteavm_gsamples_gbenchmark_gteavm_gWasmBenchmarkStarter (<WASM>[706]+29)
    at method$54org_gteavm_gsamples_gbenchmark_gteavm_gWasmBenchmarkStarter_V4_mainA16_java_glang_gString (<WASM>[179]+40)
    at Benchmark.<anonymous> (http://teavm.org/live-examples/jbox2d-benchmark/teavm-wasm-12.js:25:53)
    at http://teavm.org/live-examples/jbox2d-benchmark/teavm-wasm-12.js:137:17

Looks like this ecnounters when `extendStackI` tries to execute call_indirect and V8 thinks that function signature does not match. I'll try to investigate this issue, and report another bug if necessary.

 Issue 651751  has been merged into this issue.