Bug 258126 - [WASM] ASSERTION FAILED: !tmp.type().isV128() in JSC::Wasm::AirIRGenerator64::emitTailCallPatchpoint
Summary: [WASM] ASSERTION FAILED: !tmp.type().isV128() in JSC::Wasm::AirIRGenerator64:...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebAssembly (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2023-06-15 06:14 PDT by CAO ZONG
Modified: 2023-06-22 06:15 PDT (History)
5 users (show)

See Also:


Attachments
Reproducible poc (1.08 KB, text/javascript)
2023-06-15 06:14 PDT, CAO ZONG
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description CAO ZONG 2023-06-15 06:14:56 PDT
Created attachment 466699 [details]
Reproducible poc

Commit: fa9df2d4f442ce1c83aa934ce603fd3ce303aff0
Flags:  --useWebAssemblyTypedFunctionReferences=true --useWebAssemblyGC=true 

Backtrace:
* thread #3, name = 't Helper Thread', stop reason = signal SIGABRT
  * frame #0: 0x00007ffff5aca00b libc.so.6`raise + 203
    frame #1: 0x00007ffff5aa9859 libc.so.6`abort + 299
    frame #2: 0x00005555561c679a jsc`WTFCrashWithInfo((null)=2217, (null)="../../Source/JavaScriptCore/wasm/WasmAirIRGenerator64.cpp", (null)="CallPatchpointData JSC::Wasm::AirIRGenerator64::emitTailCallPatchpoint(BasicBlock *, const Checked<int32_t> &, const Vector<ArgumentLocation> &, const Vector<TypedTmp> &, Vector<ConstrainedTmp>)", (null)=2874) at Assertions.h:762:5
    frame #3: 0x0000555557726055 jsc`JSC::Wasm::AirIRGenerator64::emitTailCallPatchpoint(this=0x00007fffa92771c0, block=0x00007fffec294300, tailCallStackOffsetFromFP=0x00007fffa927372c, constrainedArgLocations=0x00007fffa9273868, tmpArgs=0x00007fffa9273b70, patchArgs=Vector<JSC::Wasm::AirIRGeneratorBase<JSC::Wasm::AirIRGenerator64, JSC::Wasm::TypedTmp>::ConstrainedTmp, 0UL, WTF::CrashOnOverflow, 16UL, WTF::FastMalloc> @ 0x00007fffa9273820) at WasmAirIRGenerator64.cpp:2217:9
    frame #4: 0x000055555779f916 jsc`JSC::Wasm::AirIRGeneratorBase<JSC::Wasm::AirIRGenerator64, JSC::Wasm::TypedTmp>::emitIndirectCall(this=0x00007fffa92771c0, calleeInstance=TypedTmp @ 0x00007fffa92738e0, calleeCode=TypedTmp @ 0x00007fffa92738f8, jsCalleeAnchor=TypedTmp @ 0x00007fffa9273910, signature=0x00007fffec090240, args=0x00007fffa9273b70, results=0x00007fffa9273f20, callType=TailCall) at WasmAirIRGeneratorBase.h:3833:28
    frame #5: 0x0000555557778b00 jsc`JSC::Wasm::AirIRGeneratorBase<JSC::Wasm::AirIRGenerator64, JSC::Wasm::TypedTmp>::addCallIndirect(this=0x00007fffa92771c0, tableIndex=<unavailable>, originalSignature=0x00007fffec090240, args=0x00007fffa9273b70, results=0x00007fffa9273f20, callType=TailCall) at WasmAirIRGeneratorBase.h:3738:19
    frame #6: 0x000055555774eba2 jsc`JSC::Wasm::FunctionParser<JSC::Wasm::AirIRGenerator64>::parseExpression(this=0x00007fffa92772f8) at WasmFunctionParser.h:2534:13
    frame #7: 0x0000555557742a1b jsc`JSC::Wasm::FunctionParser<JSC::Wasm::AirIRGenerator64>::parseBody(this=0x00007fffa92772f8) at WasmFunctionParser.h:365:13
    frame #8: 0x0000555557741f2c jsc`JSC::Wasm::FunctionParser<JSC::Wasm::AirIRGenerator64>::parse(this=0x00007fffa92772f8) at WasmFunctionParser.h:336:5
    frame #9: 0x0000555557730f6c jsc`std::experimental::fundamentals_v3::expected<std::unique_ptr<JSC::Wasm::InternalFunction, std::default_delete<JSC::Wasm::InternalFunction> >, WTF::String> JSC::Wasm::parseAndCompileAirImpl<JSC::Wasm::AirIRGenerator64>(compilationContext=0x00007fffa927dd30, callee=0x00007fffec2780e0, function=0x00007fffec008f40, signature=0x00007fffec030b00, unlinkedWasmToWasmCalls=0x00007fffa927dca0, info=<unavailable>, mode=<unavailable>, functionIndex=<unavailable>, hasExceptionHandlers=<unavailable>, tierUp=<unavailable>) at WasmAirIRGeneratorBase.h:3956:5
    frame #10: 0x0000555557727829 jsc`JSC::Wasm::parseAndCompileAir(compilationContext=0x00007fffa927dd30, callee=0x00007fffec2780e0, function=0x00007fffec008f40, signature=0x00007fffec030b00, unlinkedWasmToWasmCalls=0x00007fffa927dca0, info=<unavailable>, mode=<unavailable>, functionIndex=<unavailable>, hasExceptionHandlers=<unavailable>, tierUp=<unavailable>) at WasmAirIRGenerator64.cpp:2664:12
    frame #11: 0x0000555557612d1a jsc`JSC::Wasm::BBQPlan::compileFunction(this=0x0000000000000001, functionIndex=0, callee=0x00007fffec2780e0, context=0x00007fffa927dd30, unlinkedWasmToWasmCalls=0x00007fffa927dca0, tierUp=<unavailable>) at WasmBBQPlan.cpp:305:33
    frame #12: 0x0000555557611963 jsc`JSC::Wasm::BBQPlan::work(this=0x00007fffec07c210, effort=<unavailable>) at WasmBBQPlan.cpp:184:50
    frame #13: 0x0000555557884123 jsc`JSC::Wasm::Worklist::Thread::work(this=0x00007fffec027010) at WasmWorklist.cpp:111:15
    frame #14: 0x00005555579aad32 jsc`WTF::Detail::CallableWrapper<WTF::AutomaticThread::start(WTF::AbstractLocker const&)::$_0, void>::call() at AutomaticThread.cpp:229:37
    frame #15: 0x00005555579aaa39 jsc`WTF::Detail::CallableWrapper<WTF::AutomaticThread::start(WTF::AbstractLocker const&)::$_0, void>::call(this=<unavailable>) at Function.h:53:39
    frame #16: 0x00005555579d463f jsc`WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) [inlined] WTF::Function<void ()>::operator()() const at Function.h:82:35
    frame #17: 0x00005555579d462d jsc`WTF::Thread::entryPoint(newThreadContext=<unavailable>) at Threading.cpp:250:5
    frame #18: 0x0000555557a4ca56 jsc`WTF::wtfThreadEntryPoint(context=<unavailable>) at ThreadingPOSIX.cpp:242:5
    frame #19: 0x00007ffff5fd9609 libpthread.so.0`start_thread(arg=<unavailable>) at pthread_create.c:477:8
    frame #20: 0x00007ffff5ba6133 libc.so.6`__clone + 67
Comment 1 Mark Lam 2023-06-15 15:51:25 PDT
--useWebAssemblyGC=true and --useWebAssemblyGC=true are currently "experimental" (i.e. not ready shipping) features.
Comment 2 Justin Michaud 2023-06-15 16:00:57 PDT
And wasm tail calls are already known to be completely broken.

How on earth did we even get down this path if tail calls are turned off, and the new bbq jit is on by default?
Comment 3 Justin Michaud 2023-06-15 16:04:46 PDT
OK, so turning on WASM GC turns off the new BBQ jit. One mystery solved.


This poc totally needs tail calls though

justin_michaud@justinmichaudstudio OpenSource % jsc ~/Downloads/poc.js --useWebAssemblyTypedFunctionReferences=true --useWebAssemblyGC=true 
Exception: CompileError: WebAssembly.Module doesn't parse at byte 104: wasm tail calls are not enabled, in function at index 0 (evaluating 'new WebAssembly.Module(wasm_code)')
Module@[native code]
global code@/Users/justin_michaud/Downloads/poc.js:2:41


So this is not a security bug, we know wasm tail calls are broken
Comment 4 Justin Michaud 2023-06-15 16:05:53 PDT
Just confirming that this GTK release didn't accidentally turn tail calls on by default: 

v(Bool, useWebAssemblyTailCalls, false, Normal, "Allow the new instructions from the wasm tail calls spec.") \
Comment 5 Justin Michaud 2023-06-15 16:06:37 PDT
Thanks again for this poc, it will be helpful to Igalia or any OSS contributor working on any of these new features! We should make this bug public and send it to them.
Comment 6 Radar WebKit Bug Importer 2023-06-22 06:15:18 PDT
<rdar://problem/111156576>