Created attachment 393998 [details] wasm program causing the crash I'm running a prebuilt jsc, version 252179 installed through jsvu https://github.com/GoogleChromeLabs/jsvu and described here https://bugs.webkit.org/show_bug.cgi?id=179945 Consider the following wasm-program containing two mutually recursive functions: (module (type $0 (func (result i32))) (type $1 (func (param i64 i64 f64 i64 f32 i64 f32 i64 f64) (result f64))) (memory $0 8) (global $0 (mut i64) (i64.const 0)) (global $1 f64 (f64.const 0.0)) (func $0 (type 0) (global.get 1) (i64.const 0) (i64.const 0) (f64.const 0.0) (i64.const 0) (f32.const 0.0) (i64.const 0) (f32.const 0.0) (i64.const 0) (i64.const 0) (global.set 0) (f64.const 0.0) (loop (result i64) (i64.const 0)) (f64.reinterpret_i64) (f64.div) (block (result f64) (f64.const 0.0)) (f64.copysign) (call 1) (f64.le) (memory.grow) (unreachable) ) (func $1 (type 1) (local i64 i64 f64 i64 f32 i64 f32 i64 f64) (call 0) (f64.load align=1) ) (export "runi32" (func 0)) ) I instantiate a new module instance based on this and call the exported function: let buffer = new Uint8Array([ 0,97,115,109,1,0,0,0,1,146,128,128,128,0,2,96,0,1,127,96,9,126,126,124,126,125,126,125,126,124,1,124,3,131,128,128,128,0,2,0,1,5,131,128,128,128,0,1,0,8,6,146,128,128,128,0,2,126,1,66,0,11,124,0,68,0,0,0,0,0,0,0,0,11,7,138,128,128,128,0,1,6,114,117,110,105,51,50,0,0,10,234,128,128,128,0,2,200,128,128,128,0,0,35,1,66,0,66,0,68,0,0,0,0,0,0,0,0,66,0,67,0,0,0,0,66,0,67,0,0,0,0,66,0,66,0,36,0,68,0,0,0,0,0,0,0,0,3,126,66,0,11,191,163,2,124,68,0,0,0,0,0,0,0,0,11,166,16,1,101,64,0,0,11,151,128,128,128,0,8,2,126,1,124,1,126,1,125,1,126,1,125,1,126,1,124,16,0,43,0,0,11 ]); let m = new WebAssembly.Instance(new WebAssembly.Module(buffer), {}); m.exports.runi32() However when running it I don't receive a stack overflow as expected. Instead I consistently get a crash, which seems to come from the graph coloring register allocator: $ jsc jscissue2-min3.js FATAL: No color for %ftmp0 Code: BB#0: ; frequency = 1.000000 Patch &Patchpoint0, %rax, @0 Move %rax, 24(%rbp), @4 Move $0, 16(%rbp), @8 Nop @9 Patch &Patchpoint0, %rbx, %rbp, %rax, %rcx, @9 Move %rbx, %r12, @9 MoveZeroToDouble %xmm0, $0.000000(@14) MoveZeroToDouble %xmm1, $0.000000(@15) Move $0x108882018, %rax, $4438106136(@32) MoveDouble (%rax), %xmm3, @10 Move $0, %rdi, @35 Move $0, %rsi, @35 Nop Move $0, %rdx, @35 Nop Move $0, %rcx, @35 MoveFloat %xmm1, %xmm2, @35 Move $0, %r8, @35 Nop Nop @35 Patch &Patchpoint0, %xmm0, %rdi, %rsi, %xmm0, %rdx, %xmm1, %rcx, %xmm2, %r8, %xmm3, @35 Nop CompareDouble DoubleLessThanOrEqual, %ftmp0, %ftmp1, %rcx, @36 Move $0x1074c8620, %rax, $4417422880(@37) Shuffle %rbp, %rdi, 64, %r12, %rsi, 64, %rcx, %rdx, 32, @38 Patch &CCall1, %rax, %rax, %rdx, %xmm0, %rdi, %rsi, %rdx, @38 Patch &Patchpoint0, %r12, @39 Nop @40 Patch &Patchpoint0, %r12, @40 Patch &Patchpoint0, @41 Specials: &Patchpoint0: Lowered B3::PatchpointValue. &CCall1: function call that uses the C calling convention. Call arg area size: 32 /Users/jmid/.jsvu/jsc: line 2: 89263 Trace/BPT trap: 5 DYLD_FRAMEWORK_PATH="/Users/jmid/.jsvu/engines/javascriptcore" DYLD_LIBRARY_PATH="/Users/jmid/.jsvu/engines/javascriptcore" "/Users/jmid/.jsvu/engines/javascriptcore/javascriptcore" "$@"
BTW: When trying the same program in Safari I get the expected RangeError: Maximum call stack size exceeded. This indicates that it may be a recent change causing it.
I cannot reproduce this with WebKit r258739 within Safari, getting the expected "RangeError: Maximum call stack size exceeded." I also cannot reproduce with the jsc tool running against the same build. > I'm running a prebuilt jsc, version 252179 installed through jsvu https://github.com/GoogleChromeLabs/jsvu I can reproduce with this revision, which is from early November. Looks like this got fixed.