Closed Bug 1447359 Opened 4 years ago Closed 4 years ago

Assertion failure: currentOffset() - trapOffset == WasmTrapInstructionLength, at js/src/jit/MacroAssembler.cpp:3380

Categories

(Core :: JavaScript Engine, defect, P1)

ARM64
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla61
Tracking Status
firefox-esr52 --- unaffected
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- fixed

People

(Reporter: decoder, Assigned: luke)

Details

(Keywords: assertion, testcase)

Attachments

(2 files)

The attached binary WebAssembly testcase crashes on mozilla-inbound revision d0da2be2c950 (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-address-sanitizer --disable-jemalloc --enable-optimize=-O2 --without-intl-api --enable-debug --enable-simulator=arm64). To reproduce, you can run the following code in the JS shell:

var data = os.file.readFile(file, 'binary');
new WebAssembly.Instance(new WebAssembly.Module(data.buffer));



Backtrace:

==2354==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000001302c85 bp 0x7ffe63c49770 sp 0x7ffe63c496c0 T0)
==2354==The signal is caused by a WRITE memory access.
==2354==Hint: address points to the zero page.
    #0 0x1302c84 in js::jit::MacroAssembler::wasmTrap(js::wasm::Trap, js::wasm::BytecodeOffset) js/src/jit/MacroAssembler.cpp:3380:5
    #1 0x253cb5e in js::wasm::BaseCompiler::trap(js::wasm::Trap) const js/src/wasm/WasmBaselineCompile.cpp:5391:14
    #2 0x253cb5e in js::wasm::BaseCompiler::emitBody() js/src/wasm/WasmBaselineCompile.cpp:9061
    #3 0x254783a in js::wasm::BaseCompiler::emitFunction() js/src/wasm/WasmBaselineCompile.cpp:9752:10
    #4 0x254783a in js::wasm::BaselineCompileFunctions(js::wasm::ModuleEnvironment const&, js::LifoAlloc&, mozilla::Vector<js::wasm::FuncCompileInput, 8ul, js::SystemAllocPolicy> const&, js::wasm::CompiledCode*, mozilla::UniquePtr<char [], JS::FreePolicy>*) js/src/wasm/WasmBaselineCompile.cpp:9904
    #5 0x27baf25 in ExecuteCompileTask(js::wasm::CompileTask*, mozilla::UniquePtr<char [], JS::FreePolicy>*) js/src/wasm/WasmGenerator.cpp:666:14
    #6 0x27bbc29 in js::wasm::ModuleGenerator::launchBatchCompile() js/src/wasm/WasmGenerator.cpp:735:14
    #7 0x27bc897 in js::wasm::ModuleGenerator::compileFuncDef(unsigned int, unsigned int, unsigned char const*, unsigned char const*, mozilla::Vector<unsigned int, 0ul, js::SystemAllocPolicy>&&) js/src/wasm/WasmGenerator.cpp:803:45
    #8 0x270e687 in bool DecodeFunctionBody<js::wasm::Decoder>(js::wasm::Decoder&, js::wasm::ModuleGenerator&, unsigned int) js/src/wasm/WasmCompile.cpp:55:15
    #9 0x270e687 in bool DecodeCodeSection<js::wasm::Decoder>(js::wasm::ModuleEnvironment const&, js::wasm::Decoder&, js::wasm::ModuleGenerator&) js/src/wasm/WasmCompile.cpp:77
    #10 0x270d26c in js::wasm::CompileBuffer(js::wasm::CompileArgs const&, js::wasm::ShareableBytes const&, mozilla::UniquePtr<char [], JS::FreePolicy>*) js/src/wasm/WasmCompile.cpp:436:10
    #11 0x2821db1 in js::wasm::Eval(JSContext*, JS::Handle<js::TypedArrayObject*>, JS::Handle<JSObject*>, JS::MutableHandle<js::WasmInstanceObject*>) js/src/wasm/WasmJS.cpp:327:27
    #12 0x5d3aab in WasmLoop(JSContext*, unsigned int, JS::Value*) js/src/shell/js.cpp:6798:14
    #13 0x8e42d5 in js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) js/src/vm/JSContext-inl.h:290:15
[...]

SUMMARY: AddressSanitizer: SEGV js/src/jit/MacroAssembler.cpp:3380:5 in js::jit::MacroAssembler::wasmTrap(js::wasm::Trap, js::wasm::BytecodeOffset)
==2354==ABORTING
Attached file Testcase
Flags: needinfo?(luke)
Priority: -- → P1
Attached patch fix-arm64-assertSplinter Review
(Reproduces in non-ASAN with --no-threads.)  A pool was being inserted between the currentOffset() and Unreachable().
Assignee: nobody → luke
Flags: needinfo?(luke)
Attachment #8960774 - Flags: review?(lhansen)
Comment on attachment 8960774 [details] [diff] [review]
fix-arm64-assert

Review of attachment 8960774 [details] [diff] [review]:
-----------------------------------------------------------------

While you're in there:

- can you insert a similar guard in sub32FromStackPtrWithPatch? (MacroAssembler-arm64-inl.h)
- can you remove the unused 'offset' variable in nopPatchableToCall? (MacroAssembler-arm64.cpp)
Attachment #8960774 - Flags: review?(lhansen) → review+
(In reply to Lars T Hansen [:lth] from comment #3)
> - can you remove the unused 'offset' variable in nopPatchableToCall?
> (MacroAssembler-arm64.cpp)

That one is used for the return value.  It looks like we record both offsets; one for patching, one for the eventual CallSite returnAddressOffset.
Oh right.  So it probably wants a guard too, then.
Pushed by lwagner@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/fe2b18f149a1
Baldr: add AutoForbidPools in a few missing places (r=lth)
https://hg.mozilla.org/mozilla-central/rev/fe2b18f149a1
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
You need to log in before you can comment on or make changes to this bug.