1791361 - Assertion failure: end_ > begin_, at wasm/WasmCodegenTypes.h:576

Status: VERIFIED FIXED

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

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 20220912-b66bbbcc4467 (debug build, run with --fuzzing-safe --ion-offthread-compile=off):

function a(b) {
  binary = wasmTextToBinary(b);
  new WebAssembly.Module(binary);
}
oomTest(function() {
    a(`
      (tag $d)
      (func $anotherLocalFuncThrowsExn)
      (func throw $d)
      (func (try (do
        call $anotherLocalFuncThrowsExn
      )))
    `);
});

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  0x0000555557ad7b8b in js::jit::CodeGenerator::visitWasmCall(js::jit::LWasmCall*) ()
#1  0x0000555557aa49e3 in js::jit::CodeGenerator::generateBody() ()
#2  0x0000555557af1aca in js::jit::CodeGenerator::generateWasm(js::wasm::TypeIdDesc, js::wasm::BytecodeOffset, js::wasm::ArgTypeVector const&, js::jit::RegisterOffsets const&, unsigned long, js::wasm::FuncOffsets*, js::wasm::StackMaps*, js::wasm::Decoder*) ()
#3  0x0000555557db3d7e 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>*) ()
#4  0x0000555557d83a89 in ExecuteCompileTask(js::wasm::CompileTask*, mozilla::UniquePtr<char [], JS::FreePolicy>*) ()
#5  0x0000555557d84dea in js::wasm::ModuleGenerator::finishFuncDefs() ()
#6  0x0000555557d651c0 in bool DecodeCodeSection<js::wasm::Decoder>(js::wasm::ModuleEnvironment const&, js::wasm::Decoder&, js::wasm::ModuleGenerator&) ()
#7  0x0000555557d64de7 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*) ()
#8  0x0000555557dc25e6 in js::WasmModuleObject::construct(JSContext*, unsigned int, JS::Value*) ()
#9  0x000017bb63937c8e in ?? ()
[...]
#14 0x0000000000000000 in ?? ()
rax	0x55555586d3bf	93824995480511
rbx	0x0	0
rcx	0x5555582cdae8	93825039915752
rdx	0x0	0
rsi	0x7ffff7105770	140737338431344
rdi	0x7ffff7104540	140737338426688
rbp	0x7fffffff8280	140737488323200
rsp	0x7fffffff8200	140737488323072
r8	0x7ffff7105770	140737338431344
r9	0x7ffff7f99800	140737353717760
r10	0x0	0
r11	0x0	0
r12	0x7ffff480bb01	140737295465217
r13	0x7fffffff8770	140737488324464
r14	0x10	16
r15	0x7ffff4e77420	140737302197280
rip	0x555557ad7b8b <js::jit::CodeGenerator::visitWasmCall(js::jit::LWasmCall*)+2075>
=> 0x555557ad7b8b <_ZN2js3jit13CodeGenerator13visitWasmCallEPNS0_9LWasmCallE+2075>:	movl   $0x240,0x0
   0x555557ad7b96 <_ZN2js3jit13CodeGenerator13visitWasmCallEPNS0_9LWasmCallE+2086>:	callq  0x555556c349f4 <abort>

I think we had a similar issue the other day and this is likely not s-s and just a cause of OOM where the result wouldn't be used anyway, but marking it s-s nonetheless until investigated.

Comment 1

[Christian Holler (:decoder)]

Attachment: Detailed Crash Information

Comment 2

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 3

[Bugmon [:jkratzer for issues]]

Bugmon Analysis
Verified bug as reproducible on mozilla-central 20220919105141-d42e0ca4bb3e.
The bug appears to have been introduced in the following build range:

Start: 9ff3eacd30ddeaea84ae83243956190236d4c9cb (20220131144709)
End: 3fec88d4ae99148b1e5100fc0fa0e6d24926ac31 (20220131150611)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9ff3eacd30ddeaea84ae83243956190236d4c9cb&tochange=3fec88d4ae99148b1e5100fc0fa0e6d24926ac31

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Setting Regressed by field after analyzing regression range found by bugmon in comment #3.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

:rhunt, since you are the author of the regressor, bug 1750040, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1750040

Comment 7

[Ryan VanderMeulen [:RyanVM]]

For posterity, the feature in question was enabled by default for Fx100+ in bug 1759217.

Comment 8

[Ryan Hunt [:rhunt] (on leave until early May)]

Sorry, was on PTO. Looking at this now, agreed that it's likely an OOM not handled correctly.

Comment 9

[Ryan Hunt [:rhunt] (on leave until early May)]

This is indeed the same root-cause (OOM) as bug 1788213, except now in Ion instead of baseline, and is also not security sensitive for the same reason.

The assertion here is that some metadata is not zero-length, but the OOM causes no code to be emitted, which causes this metadata to be zero-length. We just need to avoid this assertion, because this code will be thrown away anyways due to the OOM. This is not security sensitive.

Comment 10

[Ryan Hunt [:rhunt] (on leave until early May)]

Attachment: Bug 1791361 - wasm: Fix the other point we setTryBodyEnd without checking for OOM. r?yury

The same issue as bug 1788213, this time in Ion.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ae0335716a95
wasm: Fix the other point we setTryBodyEnd without checking for OOM. r=yury

Comment 12

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/ae0335716a95

Comment 13

[Bugmon [:jkratzer for issues]]

Bugmon Analysis
Verified bug as fixed on rev mozilla-central 20221013100028-3662e18e5c43.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.