Bug 209333 – br_table behavior

• Component: WebAssembly
• Status: RESOLVED FIXED

[Jan M]

Created attachment 394075 [details]
wasm program causing the crash

I'm running the prebuilt JavaScriptCore, version 258753 installed through jsvu https://bugs.webkit.org/show_bug.cgi?id=179945

Consider the following wasm program:

(module
  (type $0 (func))
  (type $1 (func (result f64)))
  (func $0 (type 0))
  (func $1
    (type 1)
    (loop (result f64) (f64.const 0.0) (i32.const 0) (br_table 1) (call 0))
    (br 0)
    (unreachable)
  )
  (export "runf64" (func 1))
)

and the corresponding JavaScript validating and calling the exported function:

  let buffer = new Uint8Array([ 0,97,115,109,1,0,0,0,1,136,128,128,128,0,2,96,0,0,96,0,1,124,3,131,128,128,128,0,2,0,1,7,138,128,128,128,0,1,6,114,117,110,102,54,52,0,1,10,165,128,128,128,0,2,130,128,128,128,0,0,11,152,128,128,128,0,0,3,124,68,0,0,0,0,0,0,0,0,65,0,14,0,1,16,0,11,12,0,0,11 ]);

  print(WebAssembly.validate(buffer));
  let m = new WebAssembly.Instance(new WebAssembly.Module(buffer));
  print(m.exports.runf64().toString());

SpiderMonkey, V8, and Chakra all behave the same:

  $ sm jscissue3-validate-hyp-min.js
  true
  0
  $ v8 jscissue3-validate-hyp-min.js
  true
  0
  $ ch jscissue3-validate-hyp-min.js
  true
  0

However jsc loops as far as I can tell.

I think the cause is (br_table 1) executing with a 0 on top of the stack and an empty label list.
As I understand the standard https://webassembly.github.io/spec/core/exec/instructions.html#control-instructions
|l*| <= 0 and hence this should behave the same as (br 1), i.e., break out of the outermost control-context and therefore return. This agrees with the behavior of SpiderMonkey, V8, and Chakra.

Trying the above JS snippet in Safari 12.1.2 with AppleWebKit/605.1.15 I also get "true" and "0" as expected.
This may indicate a recent regression.

[Alexey Proskuryakov]

I can reproduce this with WebKit as shipped with macOS 10.15.4. This is all that sample says, it's just looping in wasm_entry.

Call graph:
    9415 Thread_2342286   DispatchQueue_1: com.apple.main-thread  (serial)
    + 9415 start  (in libdyld.dylib) + 1  [0x7fff6b6decc9]
    +   9415 ???  (in jsc)  load address 0x10cec7000 + 0x436b  [0x10cecb36b]
    +     9415 ???  (in jsc)  load address 0x10cec7000 + 0x56c6  [0x10cecc6c6]
    +       9415 ???  (in jsc)  load address 0x10cec7000 + 0xc64a  [0x10ced364a]
    +         9415 JSC::evaluate(JSC::JSGlobalObject*, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&)  (in JavaScriptCore) + 270  [0x7fff3580959e]
    +           9415 JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::JSGlobalObject*, JSC::JSObject*)  (in JavaScriptCore) + 12478  [0x7fff355effee]
    +             9415 vmEntryToJavaScript  (in JavaScriptCore) + 200  [0x7fff34ff82bf]
    +               9415 llint_entry  (in JavaScriptCore) + 93344  [0x7fff3500f10d]
    +                 9415 ???  (in <unknown binary>)  [0x2ebdd2601178]
    +                   9415 JSC::callWebAssemblyFunction(JSC::JSGlobalObject*, JSC::CallFrame*)  (in JavaScriptCore) + 1235  [0x7fff35adf9b3]
    +                     9415 vmEntryToJavaScript  (in JavaScriptCore) + 200  [0x7fff34ff82bf]
    +                       9415 ???  (in <unknown binary>)  [0x2ebdd260170c]
    +                         9415 wasm_entry  (in JavaScriptCore) + 13022,12990,...  [0x7fff35014322,0x7fff35014302,...]
    9415 Thread_2342288: JavaScriptCore bmalloc scavenger
    + 9415 thread_start  (in libsystem_pthread.dylib) + 15  [0x7fff6b8deb8b]
    +   9415 _pthread_start  (in libsystem_pthread.dylib) + 148  [0x7fff6b8e3109]
    +     9415 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(bmalloc::Scavenger*), bmalloc::Scavenger*> >(void*)  (in JavaScriptCore) + 39  [0x7fff35c1dec7]
    +       9415 bmalloc::Scavenger::threadEntryPoint(bmalloc::Scavenger*)  (in JavaScriptCore) + 9  [0x7fff35c1b7e9]
    +         9415 bmalloc::Scavenger::threadRunLoop()  (in JavaScriptCore) + 299  [0x7fff35c1bc1b]
    +           9415 void std::__1::condition_variable_any::wait<std::__1::unique_lock<bmalloc::Mutex> >(std::__1::unique_lock<bmalloc::Mutex>&)  (in JavaScriptCore) + 84  [0x7fff35c17414]
    +             9415 std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&)  (in libc++.1.dylib) + 18  [0x7fff689b2592]
    +               9415 _pthread_cond_wait  (in libsystem_pthread.dylib) + 698  [0x7fff6b8e3425]
    +                 9415 __psynch_cvwait  (in libsystem_kernel.dylib) + 10  [0x7fff6b822882]
    9415 Thread_2342289
      9415 start_wqthread  (in libsystem_pthread.dylib) + 15  [0x7fff6b8deb77]
        9415 _pthread_wqthread  (in libsystem_pthread.dylib) + 390  [0x7fff6b8dfaa1]
          9415 __workq_kernreturn  (in libsystem_kernel.dylib) + 10  [0x7fff6b8214ce]

[Radar WebKit Bug Importer]

<rdar://problem/60827987>

[Tadeu Zagallo]

Created attachment 394446 [details]
Patch

[EWS]

Committed r258965: <https://trac.webkit.org/changeset/258965>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 394446 [details].

[Tadeu Zagallo]

*** Bug 210105 has been marked as a duplicate of this bug. ***