The following testcase crashes on mozilla-central revision 891981e67948 (build with --32 --enable-debug --enable-more-deterministic --enable-simulator=arm, run with --fuzzing-safe --no-threads --no-baseline --no-ion): See attachment. Backtrace: #0 0x084b0ec0 in js::jit::AssemblerBufferWithConstantPools<1024u, 4u, js::jit::Instruction, js::jit::Assembler, 0u>::size (this=0xffb6508c) at js/src/jit/shared/IonAssemblerBufferWithConstantPools.h:712 #1 js::jit::Assembler::size (this=0xffb64f00) at js/src/jit/arm/Assembler-arm.cpp:1412 #2 0x089644f8 in js::wasm::ModuleGenerator::finishCodegen (this=0xffb64a34) at js/src/wasm/WasmGenerator.cpp:530 #3 0x0897dcc3 in js::wasm::ModuleGenerator::finish (this=0xffb64a34, bytecode=...) at js/src/wasm/WasmGenerator.cpp:1108 #4 0x089268ff in js::wasm::Compile (bytecode=..., args=..., error=0xffb65734) at js/src/wasm/WasmCompile.cpp:134 /snip For detailed crash information, see attachment.

autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: https://hg.mozilla.org/mozilla-central/rev/4701cf47fa90 user: Luke Wagner date: Wed Mar 22 17:11:48 2017 -0500 summary: Bug 1334504 - Baldr: always enable profiling prologue (r=bbouvier) Luke/Benjamin, is bug 1334504 a likely regressor?

Thread 1 "js-32-dm-armSim" received signal SIGSEGV, Segmentation fault. 0x083cedf6 in memcpy (__len=8, __src=<synthetic pointer>, __dest=0x26007b70) at /usr/include/i386-linux-gnu/bits/string3.h:53 53 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); (gdb) bt #0 0x083cedf6 in memcpy (__len=8, __src=<synthetic pointer>, __dest=0x26007b70) at /usr/include/i386-linux-gnu/bits/string3.h:53 #1 js::jit::Simulator::writeQ (f=js::jit::Simulator::ForbidUnaligned, instr=0x26007b80, value=0, addr=637565808, this=0xf7923000) at /home/gkwubu/trees/mozilla-central/js/src/jit/arm/Simulator-arm.cpp:1618 #2 js::jit::Simulator::decodeType6CoprocessorIns (this=0xf7923000, instr=0x26007b80) at /home/gkwubu/trees/mozilla-central/js/src/jit/arm/Simulator-arm.cpp:4465 #3 0x083dcc0a in js::jit::Simulator::decodeType6 (instr=0x26007b80, this=0xf7923000) at /home/gkwubu/trees/mozilla-central/js/src/jit/arm/Simulator-arm.cpp:3721 #4 js::jit::Simulator::instructionDecode (this=0xf7923000, instr=0x26007b80) at /home/gkwubu/trees/mozilla-central/js/src/jit/arm/Simulator-arm.cpp:4702 #5 0x083dd1ea in js::jit::Simulator::execute<false> (this=0xf7923000) at /home/gkwubu/trees/mozilla-central/js/src/jit/arm/Simulator-arm.cpp:4760 #6 js::jit::Simulator::callInternal (this=0xf7923000, entry=0x260079b0 "\a") at /home/gkwubu/trees/mozilla-central/js/src/jit/arm/Simulator-arm.cpp:4848 #7 0x083dd4ac in js::jit::Simulator::call (this=0xf7923000, entry=0x260079b0 "\a", argument_count=<optimized out>) at /home/gkwubu/trees/mozilla-central/js/src/jit/arm/Simulator-arm.cpp:4931 #8 0x086ddf6c in js::wasm::Instance::callExport (this=0xf68577f0, cx=0xf794f800, funcIndex=4, args=...) at /home/gkwubu/trees/mozilla-central/js/src/wasm/WasmInstance.cpp:655 #9 0x086de7ba in WasmCall (cx=0xf794f800, argc=0, vp=0xf6711058) at /home/gkwubu/trees/mozilla-central/js/src/wasm/WasmJS.cpp:1114 #10 0x0813fccb in js::CallJSNative (args=..., native=0x86de740 <WasmCall(JSContext*, unsigned int, JS::Value*)>, cx=0xf794f800) at /home/gkwubu/trees/mozilla-central/js/src/jscntxtinlines.h:291 #11 js::InternalCallOrConstruct (cx=0xf794f800, args=..., construct=js::NO_CONSTRUCT) at /home/gkwubu/trees/mozilla-central/js/src/vm/Interpreter.cpp:455 #12 0x08140334 in InternalCall (cx=<optimized out>, args=...) at /home/gkwubu/trees/mozilla-central/js/src/vm/Interpreter.cpp:500 #13 0x08132e30 in js::CallFromStack (args=..., cx=<optimized out>) at /home/gkwubu/trees/mozilla-central/js/src/vm/Interpreter.cpp:506 #14 Interpret (cx=0x0, cx@entry=0xf794f800, state=...) at /home/gkwubu/trees/mozilla-central/js/src/vm/Interpreter.cpp:2997 #15 0x0813f8d3 in js::RunScript (cx=0xf794f800, state=...) at /home/gkwubu/trees/mozilla-central/js/src/vm/Interpreter.cpp:395 #16 0x08141b44 in js::ExecuteKernel (result=0x0, evalInFrame=..., newTargetValue=..., envChainArg=..., script=..., cx=0xf794f800) at /home/gkwubu/trees/mozilla-central/js/src/vm/Interpreter.cpp:684 #17 js::Execute (cx=0xf794f800, script=..., envChainArg=..., rval=0x0) at /home/gkwubu/trees/mozilla-central/js/src/vm/Interpreter.cpp:717 #18 0x083e79a3 in ExecuteScript (cx=cx@entry=0xf794f800, scope=scope@entry=..., script=..., script@entry=..., rval=0x0) at /home/gkwubu/trees/mozilla-central/js/src/jsapi.cpp:4523 #19 0x083ee669 in JS_ExecuteScript (cx=0xf794f800, scriptArg=...) at /home/gkwubu/trees/mozilla-central/js/src/jsapi.cpp:4556 #20 0x0807060d in RunFile (compileOnly=false, file=0xf68e9880, filename=<optimized out>, cx=0xf794f800) at /home/gkwubu/trees/mozilla-central/js/src/shell/js.cpp:714 #21 Process (cx=0xf794f800, filename=0xffffd0c5 "bb956749.js", forceTTY=false, kind=FileScript) at /home/gkwubu/trees/mozilla-central/js/src/shell/js.cpp:1161 #22 0x08076cfc in ProcessArgs (op=0xffffcce0, cx=<optimized out>) at /home/gkwubu/trees/mozilla-central/js/src/shell/js.cpp:7901 #23 Shell (envp=<optimized out>, op=0xffffcce0, cx=<optimized out>) at /home/gkwubu/trees/mozilla-central/js/src/shell/js.cpp:8264 #24 main (argc=6, argv=0xffffce24, envp=0xffffce40) at /home/gkwubu/trees/mozilla-central/js/src/shell/js.cpp:8664 (gdb) x/i $pc => 0x83cedf6 <js::jit::Simulator::decodeType6CoprocessorIns(js::jit::SimInstruction*)+950>: mov %eax,(%ebx) (gdb) x/b $eax 0x0: Cannot access memory at address 0x0 (gdb) x/b $ebx 0x26007b70: 0x40 (gdb)

For comment 4: reproduced on m-c rev 891981e67948, run with --fuzzing-safe --no-threads --no-baseline --no-ion CC="gcc -m32 -msse2 -mfpmath=sse" CXX="g++ -m32 -msse2 -mfpmath=sse" AR=ar PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig sh ./configure --target=i686-pc-linux --enable-simulator=arm --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests Let's lock this s-s as a start even though it seems to be a null deref, as memcpy is involved.

I'm on it. This was hard to repro, because this is a --enable-deterministic only failure: we canonicalize FP values in more-deterministic mode only, in some places, and never flush the pool entries. I don't think this is s-s, since we don't use the --enable-deterministic flag in release.

Still no test, since this is enable-more-deterministic only.

Opening up.

Comment on attachment 8854438 [details] [diff] [review] fix.patch We discussed this and we'll try a more general approach here.

Tracking for a bug in FF55 in wasm.

Removing tracking. Benjamin told me this only happens in more-deterministic builds.

Comment on attachment 8856575 [details] Bug 1353352: Always flush constant pools at the end of stubs; https://reviewboard.mozilla.org/r/128528/#review130942 Thanks, looks great. Could you also put a flush() at the end of ModuleGenerator::patchCallSite()? That should cover our three categories of code (function bodies, stubs, the jump islands). ::: js/src/wasm/WasmStubs.cpp:40 (Diff revision 1) > +FinishOffsets(MacroAssembler& masm, Offsets* offsets) > +{ > + // On old ARM hardware, constant pools could be inserted and they need to > + // be flushed before considering the size of the masm. > + masm.flushBuffer(); > + offsets->end = masm.currentOffset(); How about using masm.size() which is assert()ier

Pushed by bbouvier@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/a2b881c8116f Always flush constant pools at the end of stubs; r=luke