1350550 - Assertion failure: pool_.numEntries() == 0, at js/src/jit/shared/IonAssemblerBufferWithConstantPools.h:712 or Crash [@ js::jit::Simulator::instructionDecode] with --arm-hwcap=vfp

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 72bc265f157f (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-stdcxx-compat --disable-profiling --enable-debug --without-intl-api --enable-optimize --target=i686-pc-linux-gnu --enable-simulator=arm, run with --fuzzing-safe --arm-hwcap=vfp min.js):

lfModule = new WebAssembly.Module(wasmTextToBinary(`
(module (import $i "a" "b" (param i64) (result i64)) (func $f (result i32) (i32.wrap/i64 (call $i (i64.const 42)))) (export "f" $f))
`));


Backtrace:

 received signal SIGSEGV, Segmentation fault.
0x084920d0 in js::jit::AssemblerBufferWithConstantPools<1024u, 4u, js::jit::Instruction, js::jit::Assembler, 0u>::size (this=0xffffc69c) at js/src/jit/shared/IonAssemblerBufferWithConstantPools.h:712
#0  0x084920d0 in js::jit::AssemblerBufferWithConstantPools<1024u, 4u, js::jit::Instruction, js::jit::Assembler, 0u>::size (this=0xffffc69c) at js/src/jit/shared/IonAssemblerBufferWithConstantPools.h:712
#1  js::jit::Assembler::size (this=0xffffc510) at js/src/jit/arm/Assembler-arm.cpp:1412
#2  0x088fa0a6 in js::wasm::ModuleGenerator::finishCodegen (this=0xffffc044) at js/src/wasm/WasmGenerator.cpp:527
#3  0x088ff879 in js::wasm::ModuleGenerator::finish (this=0xffffc044, bytecode=...) at js/src/wasm/WasmGenerator.cpp:1105
#4  0x08900fc7 in js::wasm::Compile (bytecode=..., args=..., error=0xffffcd44) at js/src/wasm/WasmCompile.cpp:134
#5  0x0895c024 in js::WasmModuleObject::construct (cx=0xf7940800, argc=1, vp=0xf5054060) at js/src/wasm/WasmJS.cpp:888
#6  0x08179217 in js::CallJSNative (cx=0xf7940800, native=0x895be50 <js::WasmModuleObject::construct(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:282
[...]
#19 main (argc=4, argv=0xffffd8a4, envp=0xffffd8b8) at js/src/shell/js.cpp:8456
eax	0x0	0
ebx	0x8cd3ff4	147668980
ecx	0xf7da4864	-136689564
edx	0x0	0
esi	0xffffc044	-16316
edi	0xffffc510	-15088
ebp	0xffffb6e8	4294948584
esp	0xffffb6e0	4294948576
eip	0x84920d0 <js::jit::Assembler::size() const+96>
=> 0x84920d0 <js::jit::Assembler::size() const+96>:	movl   $0x0,0x0
   0x84920da <js::jit::Assembler::size() const+106>:	ud2    



This is trigger-happy right now, fuzzblocker.

Comment 1

[Christian Holler (:decoder)]

NI for Benjamin due to wasm involved.

Comment 2

[Christian Holler (:decoder)]

Apparently this only reproduces with --arm-hwcap=vfp and has to do with passing i64.

Comment 3

[Benjamin Bouvier [:bbouvier] (inactive)]

Wow, it's actually already blowing up in the test suite, but we don't explicitly test --arm-hwcap=vfp on treeherder... Simple fix though.

Comment 4

[Lars T Hansen [:lth]]

(In reply to Benjamin Bouvier [:bbouvier] from comment #3)
> Wow, it's actually already blowing up in the test suite, but we don't
> explicitly test --arm-hwcap=vfp on treeherder... Simple fix though.

Nor should we be, because that's a Tier-3 configuration, see bug 1350552 comment 3.

Comment 5

[Benjamin Bouvier [:bbouvier] (inactive)]

Attachment: tableentry.patch

Not including the test because it's not tested on tbpl anyways. It is hard to say for sure that it fixes the issue, because running the test suite with --arm-hwcap completely fails, and for good reason (see Lars' comment above).

Comment 6

[Luke Wagner [:luke]]

Comment on attachment 8851573 [details] [diff] [review]
tableentry.patch

Nice, thanks!

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/321145f0ce16
Flush constant pool in wasm table entry; r=luke

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/321145f0ce16