Bug 209294 – Register allocation crash? FATAL: No color for %ftmp0

• Component: WebAssembly
• Status: RESOLVED CONFIGURATION CHANGED

[Jan M]

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" "$@"

[Jan M]

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.

[Alexey Proskuryakov]

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.