Closed Bug 1435293 Opened 5 years ago Closed 5 years ago

Assertion failure: sizeof(fmt2) >= strlen(fmt) + live_ + 1, at js/src/jit/shared/Disassembler-shared.cpp:76

Categories

(Core :: JavaScript Engine, defect)

ARM
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla60
Tracking Status
firefox-esr52 --- unaffected
firefox58 --- unaffected
firefox59 --- wontfix
firefox60 --- fixed

People

(Reporter: decoder, Assigned: lth)

Details

(4 keywords, Whiteboard: [jsbugmon:update,bisect])

Attachments

(2 files)

The following testcase crashes on mozilla-central revision 9746e0a0a81c (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --without-intl-api --enable-optimize --target=i686-pc-linux-gnu --enable-simulator=arm, run with --fuzzing-safe --cpu-count=2 --disable-oom-functions --disable-oom-functions --ion-eager):

See attachment.


Backtrace:

received signal SIGSEGV, Segmentation fault.
0x0857a27c in js::jit::DisassemblerSpew::spew (this=0xffffa250, fmt=0x8b5bd8a "%s%d:    ; .orphan") at js/src/jit/shared/Disassembler-shared.cpp:76
#0  0x0857a27c in js::jit::DisassemblerSpew::spew (this=0xffffa250, fmt=0x8b5bd8a "%s%d:    ; .orphan") at js/src/jit/shared/Disassembler-shared.cpp:76
#1  0x0857a4e2 in js::jit::DisassemblerSpew::spewOrphans (this=0xffffa250) at js/src/jit/shared/Disassembler-shared.cpp:194
#2  0x084fcde0 in js::jit::Assembler::finishDisassembler (this=<optimized out>) at js/src/jit/arm/Assembler-arm.cpp:3311
#3  0x08276a19 in js::jit::Assembler::~Assembler (this=0xffff9eb8, __in_chrg=<optimized out>) at js/src/jit/arm/Assembler-arm.h:1330
#4  js::jit::MacroAssemblerARM::~MacroAssemblerARM (this=0xffff9eb8, __in_chrg=<optimized out>) at js/src/jit/arm/MacroAssembler-arm.h:29
#5  js::jit::MacroAssemblerARMCompat::~MacroAssemblerARMCompat (this=0xffff9eb8, __in_chrg=<optimized out>) at js/src/jit/arm/MacroAssembler-arm.h:524
#6  js::jit::MacroAssembler::~MacroAssembler (this=0xffff9eb8, __in_chrg=<optimized out>) at js/src/jit/MacroAssembler.h:233
#7  js::jit::BaselineCompilerShared::~BaselineCompilerShared (this=0xffff9eac, __in_chrg=<optimized out>) at js/src/jit/shared/BaselineCompiler-shared.h:18
#8  js::jit::BaselineCompilerARM::~BaselineCompilerARM (this=0xffff9eac, __in_chrg=<optimized out>) at js/src/jit/arm/BaselineCompiler-arm.h:15
#9  js::jit::BaselineCompiler::~BaselineCompiler (this=0xffff9eac, __in_chrg=<optimized out>) at js/src/jit/BaselineCompiler.h:261
#10 js::jit::BaselineCompile (cx=0xf6e1d800, script=0xe8be3b88, forceDebugInstrumentation=false) at js/src/jit/BaselineJIT.cpp:247
#11 0x0827890c in CanEnterBaselineJIT (cx=cx@entry=0xf6e1d800, script=script@entry=..., osrFrame=osrFrame@entry=0x0) at js/src/jit/BaselineJIT.cpp:300
#12 0x08278aa7 in js::jit::CanEnterBaselineMethod (cx=0xf6e1d800, state=...) at js/src/jit/BaselineJIT.cpp:353
#13 0x08364c05 in js::jit::CanEnterIon (cx=0xf6e1d800, state=...) at js/src/jit/Ion.cpp:2538
#14 0x083ae8f9 in js::jit::MaybeEnterJit (cx=0xf6e1d800, state=...) at js/src/jit/Jit.cpp:140
#15 0x081a28e5 in js::RunScript (cx=0xf6e1d800, state=...) at js/src/vm/Interpreter.cpp:408
#16 0x081a4f66 in js::ExecuteKernel (cx=0xf6e1d800, script=..., envChainArg=..., newTargetValue=..., evalInFrame=..., result=0xf5fffd98) at js/src/vm/Interpreter.cpp:706
#17 0x081a5487 in js::Execute (cx=0xf6e1d800, script=..., envChainArg=..., rval=0xf5fffd98) at js/src/vm/Interpreter.cpp:739
#18 0x0859bd58 in ExecuteScript (cx=cx@entry=0xf6e1d800, scope=..., scope@entry=..., script=script@entry=..., rval=0xf5fffd98) at js/src/jsapi.cpp:4715
#19 0x0859c2b2 in ExecuteScript (cx=0xf6e1d800, envChain=..., scriptArg=..., scriptArg@entry=..., rval=0xf5fffd98) at js/src/jsapi.cpp:4734
#20 0x0859c3a8 in JS_ExecuteScript (cx=<optimized out>, envChain=..., scriptArg=..., rval=...) at js/src/jsapi.cpp:4755
#21 0x080a9466 in Evaluate (cx=0xf6e1d800, argc=1, vp=0xf5fffd98) at js/src/shell/js.cpp:1920
#22 0x081ad929 in js::CallJSNative (cx=0xf6e1d800, native=0x80a8930 <Evaluate(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:291
#23 0x081a2dcd in js::InternalCallOrConstruct (cx=0xf6e1d800, args=..., construct=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:473
#24 0x081a3190 in InternalCall (cx=cx@entry=0xf6e1d800, args=...) at js/src/vm/Interpreter.cpp:522
#25 0x081a32ff in js::CallFromStack (cx=0xf6e1d800, args=...) at js/src/vm/Interpreter.cpp:528
#26 0x082808fc in js::jit::DoCallFallback (cx=0xf6e1d800, frame=0xf5fffde0, stub_=0xe2601cd0, argc=1, vp=0xf5fffd98, res=...) at js/src/jit/BaselineIC.cpp:2560
#27 0x08570bb0 in js::jit::Simulator::softwareInterrupt (this=0xf6e59000, instr=0xf6e7b0e4) at js/src/jit/arm/Simulator-arm.cpp:2738
#28 0x085713b6 in js::jit::Simulator::decodeType7 (this=0xf6e59000, instr=0xf6e7b0e4) at js/src/jit/arm/Simulator-arm.cpp:3905
#29 0x0856f222 in js::jit::Simulator::instructionDecode (this=0xf6e59000, instr=0xf6e7b0e4) at js/src/jit/arm/Simulator-arm.cpp:4885
#30 0x08572d14 in js::jit::Simulator::execute<false> (this=0xf6e59000) at js/src/jit/arm/Simulator-arm.cpp:4955
#31 js::jit::Simulator::callInternal (this=0xf6e59000, entry=0x3b2c1810 "\360O-\351\004\320M\342\020\212-\355\r\200\240\341h\220\235\345\r\260\240\341t\240\235", <incomplete sequence \345>) at js/src/jit/arm/Simulator-arm.cpp:5040
#32 0x08573091 in js::jit::Simulator::call (this=<optimized out>, entry=<optimized out>, argument_count=<optimized out>) at js/src/jit/arm/Simulator-arm.cpp:5123
#33 0x083ae0ba in EnterJit (cx=cx@entry=0xf6e1d800, state=..., code=0x3d171008 "\004\340-\345\a") at js/src/jit/Jit.cpp:101
#34 0x083ae91f in js::jit::MaybeEnterJit (cx=0xf6e1d800, state=...) at js/src/jit/Jit.cpp:163
#35 0x081a28e5 in js::RunScript (cx=0xf6e1d800, state=...) at js/src/vm/Interpreter.cpp:408
#36 0x081a4f66 in js::ExecuteKernel (cx=0xf6e1d800, script=..., envChainArg=..., newTargetValue=..., evalInFrame=..., result=0xf5fffed0) at js/src/vm/Interpreter.cpp:706
#37 0x081d6df7 in EvalKernel (cx=0xf6e1d800, v=..., evalType=evalType@entry=INDIRECT_EVAL, caller=..., env=..., pc=0x0, vp=...) at js/src/builtin/Eval.cpp:324
#38 0x081d7170 in js::IndirectEval (cx=0xf6e1d800, argc=1, vp=0xf5fffed0) at js/src/builtin/Eval.cpp:417
#39 0x081ad929 in js::CallJSNative (cx=0xf6e1d800, native=0x81d70b0 <js::IndirectEval(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:291
#40 0x081a2dcd in js::InternalCallOrConstruct (cx=0xf6e1d800, args=..., construct=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:473
#41 0x081a3190 in InternalCall (cx=cx@entry=0xf6e1d800, args=...) at js/src/vm/Interpreter.cpp:522
#42 0x081a32ff in js::CallFromStack (cx=0xf6e1d800, args=...) at js/src/vm/Interpreter.cpp:528
#43 0x082808fc in js::jit::DoCallFallback (cx=0xf6e1d800, frame=0xf5ffff10, stub_=0xf5c6e370, argc=1, vp=0xf5fffed0, res=...) at js/src/jit/BaselineIC.cpp:2560
#44 0x08570bb0 in js::jit::Simulator::softwareInterrupt (this=0xf6e59000, instr=0xf6e7b0e4) at js/src/jit/arm/Simulator-arm.cpp:2738
#45 0x085713b6 in js::jit::Simulator::decodeType7 (this=0xf6e59000, instr=0xf6e7b0e4) at js/src/jit/arm/Simulator-arm.cpp:3905
#46 0x0856f222 in js::jit::Simulator::instructionDecode (this=0xf6e59000, instr=0xf6e7b0e4) at js/src/jit/arm/Simulator-arm.cpp:4885
#47 0x08572d14 in js::jit::Simulator::execute<false> (this=0xf6e59000) at js/src/jit/arm/Simulator-arm.cpp:4955
#48 js::jit::Simulator::callInternal (this=0xf6e59000, entry=0x3b2c1810 "\360O-\351\004\320M\342\020\212-\355\r\200\240\341h\220\235\345\r\260\240\341t\240\235", <incomplete sequence \345>) at js/src/jit/arm/Simulator-arm.cpp:5040
#49 0x08573091 in js::jit::Simulator::call (this=<optimized out>, entry=<optimized out>, argument_count=<optimized out>) at js/src/jit/arm/Simulator-arm.cpp:5123
#50 0x083ae0ba in EnterJit (cx=cx@entry=0xf6e1d800, state=..., code=0x3b2d1008 "\004\340-\345\a") at js/src/jit/Jit.cpp:101
#51 0x083ae91f in js::jit::MaybeEnterJit (cx=0xf6e1d800, state=...) at js/src/jit/Jit.cpp:163
#52 0x081a28e5 in js::RunScript (cx=0xf6e1d800, state=...) at js/src/vm/Interpreter.cpp:408
[...]
#61 main (argc=7, argv=0xffffcd84, envp=0xffffcda4) at js/src/shell/js.cpp:9307
eax	0x0	0
ebx	0x8dcbff4	148684788
ecx	0xf7d9f864	-136710044
edx	0x0	0
esi	0xffffa250	-23984
edi	0x8b5bd8a	146128266
ebp	0xffff9e08	4294942216
esp	0xffff99d0	4294941136
eip	0x857a27c <js::jit::DisassemblerSpew::spew(char const*, ...)+268>
=> 0x857a27c <js::jit::DisassemblerSpew::spew(char const*, ...)+268>:	movl   $0x0,0x0
   0x857a286 <js::jit::DisassemblerSpew::spew(char const*, ...)+278>:	ud2


The attached testcase is totally unreduced, but I managed to pack it into a single file. It is only slightly intermittent but turns more intermittent the more I try to reduce it. It still happens fairly frequently in fuzzing since recently.
Attached file Testcase
Assignee: nobody → lhansen
Status: NEW → ASSIGNED
5MB of JS+wasm binary blobs?  Thank you sir, may I please have another...
I'll try to repro, but this is basically easy to fix.  Right now there's a counter that keeps track of the number of concurrently active assemblers, and in order to distinguish one disasm spew from another (as when one assembler is created for an IC stub while we're assembling another program) then it prefixes "nested" assemblers' disasm with a string of ">".  These are accumulated in a buffer that is fixed.  The assertion says that the buffer was exhausted, ie, there were too many concurrently active assemblers.

The fundamental flaw is that these assemblers are not "nested", they are really concurrent, and lots of things can be in flight at the same time in the engine, and misc lifetime decisions conspire to have more assemblers live at the same time than I anticipated.  It's possible the number can be quite large in very artificial cases (the browser should not be affected as the disasm should be shell-only and debug-only).

The right fix is to think differently about these concurrently live assemblers.  We should prefix not by a string of ">", because the assemblers are not nested, but by a character that distinguishes them.  For example, we might just index mod 63 into " abc..zABC..Z01..9" and call that good enough, as far as tagging is concerned.  This will occasionally cause confusion but never during testing/debugging where we care about the disassembly.
More robust tagging.  See commit msg for technical info.

Christian, I can't repro your crash, but perhaps you can apply this patch and check that the crash is gone?
Attachment #8948359 - Flags: review?(nicolas.b.pierron)
Attachment #8948359 - Flags: feedback?(choller)
Attachment #8948359 - Flags: review?(nicolas.b.pierron) → review+
Pushed by lhansen@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/151fa6679622
More robust tagging of assemblers during disassembly.  r=nbp
https://hg.mozilla.org/mozilla-central/rev/151fa6679622
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
How far back does this go?
Flags: needinfo?(lhansen)
Initial code landed December 15 2017.

This code is for internal use only, should not be enabled in any release product, to the best of my knowledge.  It is gated on --enable-debug.  So if you're thinking about uplift, there's no reason to.
Flags: needinfo?(lhansen)
Comment on attachment 8948359 [details] [diff] [review]
bug1435293-robust-assembler-tagging.patch

This is gone in fuzzing, so I assume the patch fixed it :)
Attachment #8948359 - Flags: feedback?(choller) → feedback+
You need to log in before you can comment on or make changes to this bug.