1711636 - Assertion failure: from.toStackSlot()->slot() % SimdMemoryAlignment == 0, at js/src/jit/LIR.cpp:654

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, defect, P2)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 3210b5354d3e (debug build, run with --no-threads --fuzzing-safe --wasm-compiler=optimizing test.js):

See attachment.

Backtrace:

==20465==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0xaaaac9cf842c bp 0xffffea93e0c0 sp 0xffffea93e0a0 T20465)
==20465==The signal is caused by a WRITE memory access.
==20465==Hint: address points to the zero page.
    #0 0xaaaac9cf842c in js::jit::LMoveGroup::add(js::jit::LAllocation, js::jit::LAllocation, js::jit::LDefinition::Type) js/src/jit/LIR.cpp
    #1 0xaaaaca2931cc in js::jit::BacktrackingAllocator::addMove(js::jit::LMoveGroup*, js::jit::LiveRange*, js::jit::LiveRange*, js::jit::LDefinition::Type) js/src/jit/BacktrackingAllocator.h:688:19
    #2 0xaaaaca2931cc in js::jit::BacktrackingAllocator::moveInput(js::jit::LInstruction*, js::jit::LiveRange*, js::jit::LiveRange*, js::jit::LDefinition::Type) js/src/jit/BacktrackingAllocator.h:697:12
    #3 0xaaaaca2931cc in js::jit::BacktrackingAllocator::resolveControlFlow() js/src/jit/BacktrackingAllocator.cpp:2101:14
    #4 0xaaaaca28ffd0 in js::jit::BacktrackingAllocator::go() js/src/jit/BacktrackingAllocator.cpp:923:8
    #5 0xaaaac9c24c08 in js::jit::GenerateLIR(js::jit::MIRGenerator*) js/src/jit/Ion.cpp:1530:23
    #6 0xaaaaca02d464 in js::wasm::IonCompileFunctions(js::wasm::ModuleEnvironment const&, js::wasm::CompilerEnvironment const&, js::LifoAlloc&, mozilla::Vector<js::wasm::FuncCompileInput, 8ul, js::SystemAllocPolicy> const&, js::wasm::CompiledCode*, mozilla::UniquePtr<char [], JS::FreePolicy>*) js/src/wasm/WasmIonCompile.cpp:5728:23
    #7 0xaaaac9feb5f0 in ExecuteCompileTask(js::wasm::CompileTask*, mozilla::UniquePtr<char [], JS::FreePolicy>*) js/src/wasm/WasmGenerator.cpp:714:16
    #8 0xaaaac9fcc58c in js::wasm::ModuleGenerator::locallyCompileCurrentTask() js/src/wasm/WasmGenerator.cpp:775:8
    #9 0xaaaac9fcc58c in js::wasm::ModuleGenerator::finishFuncDefs() js/src/wasm/WasmGenerator.cpp:913:24
    #10 0xaaaac9fcc58c in bool DecodeCodeSection<js::wasm::Decoder>(js::wasm::ModuleEnvironment const&, js::wasm::Decoder&, js::wasm::ModuleGenerator&) js/src/wasm/WasmCompile.cpp:686:13
    #11 0xaaaac9fc996c in js::wasm::CompileBuffer(js::wasm::CompileArgs const&, js::wasm::ShareableBytes const&, mozilla::UniquePtr<char [], JS::FreePolicy>*, mozilla::Vector<mozilla::UniquePtr<char [], JS::FreePolicy>, 0ul, js::SystemAllocPolicy>*, JS::OptimizedEncodingListener*) js/src/wasm/WasmCompile.cpp:708:8
    #12 0xaaaaca044828 in js::WasmModuleObject::construct(JSContext*, unsigned int, JS::Value*) js/src/wasm/WasmJS.cpp:1522:7
    #13 0xaaaac8cd4a08 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) js/src/vm/Interpreter.cpp:427:13
    #14 0xaaaac8cd8a98 in CallJSNativeConstructor(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) js/src/vm/Interpreter.cpp:443:8
    #15 0xaaaac8cc8f48 in InternalConstruct(JSContext*, js::AnyConstructArgs const&) js/src/vm/Interpreter.cpp:616:14
    #16 0xaaaac8cbecf4 in js::ConstructFromStack(JSContext*, JS::CallArgs const&) js/src/vm/Interpreter.cpp:662:10
    #17 0xaaaac8cbecf4 in Interpret(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:3217:16
    [...]

Fuzzblocker based on the frequency of the crash and marking s-s due to JIT assert.

Comment 1

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 2

[Nicolas B. Pierron [:nbp]]

Julian, sounds like we might have to change the register allocator to align SIMD spill.

Comment 3

[Lars T Hansen [:lth]]

So far we've not been making any assumption that spilled SIMD values are aligned, so it could also be that we would just remove the assertion. I've removed others, if memory serves.

Comment 4

[Lars T Hansen [:lth]]

In fact, comment at that line in LIR.cpp:

#  ifdef ENABLE_WASM_SIMD
  // Alignment is not currently required for SIMD on x86/x64.  See also
  // CodeGeneratorShared::CodeGeneratorShared and in general everywhere
  // SimdMemoryAignment is used.  Likely, alignment requirements will return.
#    if !defined(JS_CODEGEN_X86) && !defined(JS_CODEGEN_X64)
...

We just need to extend the inner ifdef I think.

Comment 5

[Julian Seward [:jseward]]

Attachment: Bug 1711636 - Assertion failure: from.toStackSlot()->slot() % SimdMemoryAlignment == 0, at js/src/jit/LIR.cpp:654. r=lth.

This assertion is overly constraining: in fact we don't require or provide
naturally-aligned 128-bit accesses to the stack on arm64. So disable it for
arm64.

Comment 6

[Lars T Hansen [:lth]]

Not a security bug, btw. Can we open?

Comment 7

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/69ebfd62d6a3