1411956 - Assertion failure: !minimalBundle(bundle), at js/src/jit/BacktrackingAllocator.cpp:1360 with enableGeckoProfiling

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P2)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision d49501f258b1 (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, run with --fuzzing-safe --ion-offthread-compile=off --ion-eager):

enableGeckoProfiling();
class base {}
class derived extends base {
    testElem() {
        super[ruin()];
    }
}
let instance = new derived();
instance.testElem();


Backtrace:

received signal SIGSEGV, Segmentation fault.
0x08ad0cea in js::jit::BacktrackingAllocator::processBundle (this=0xffffb708, mir=0xf52ce0f8, bundle=0xf52d23d8) at js/src/jit/BacktrackingAllocator.cpp:1360
#0  0x08ad0cea in js::jit::BacktrackingAllocator::processBundle (this=0xffffb708, mir=0xf52ce0f8, bundle=0xf52d23d8) at js/src/jit/BacktrackingAllocator.cpp:1360
#1  0x08ad2c04 in js::jit::BacktrackingAllocator::go (this=0xffffb708) at js/src/jit/BacktrackingAllocator.cpp:871
#2  0x0832a051 in js::jit::GenerateLIR (mir=0xf52ce0f8) at js/src/jit/Ion.cpp:1902
#3  0x0834dd61 in js::jit::CompileBackEnd (mir=0xf52ce0f8) at js/src/jit/Ion.cpp:1970
#4  0x08074f74 in js::jit::IonCompile (cx=cx@entry=0xf791d000, script=<optimized out>, baselineFrame=baselineFrame@entry=0x0, osrPc=0x0, recompile=false, optimizationLevel=js::jit::OptimizationLevel::Normal) at js/src/jit/Ion.cpp:2257
#5  0x0834e25d in js::jit::Compile (cx=cx@entry=0xf791d000, script=script@entry=..., osrFrame=osrFrame@entry=0x0, osrPc=0x0, forceRecompile=false) at js/src/jit/Ion.cpp:2450
#6  0x0834e3b0 in js::jit::CanEnterIon (cx=0xf791d000, state=...) at js/src/jit/Ion.cpp:2534
#7  0x08375bed in js::jit::MaybeEnterJit (cx=0xf791d000, state=...) at js/src/jit/Jit.cpp:147
#8  0x08186175 in js::RunScript (cx=0xf791d000, state=...) at js/src/vm/Interpreter.cpp:408
#9  0x08186715 in js::InternalCallOrConstruct (cx=0xf791d000, args=..., construct=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:495
#10 0x08186a0f in InternalCall (cx=cx@entry=0xf791d000, args=...) at js/src/vm/Interpreter.cpp:522
#11 0x08186b7f in js::CallFromStack (cx=0xf791d000, args=...) at js/src/vm/Interpreter.cpp:528
#12 0x0825c81c in js::jit::DoCallFallback (cx=0xf791d000, frame=0xffffc2f8, stub_=0xf52b0308, argc=0, vp=0xffffc2c0, res=...) at js/src/jit/BaselineIC.cpp:2539
[...]
#16 0x083752f6 in EnterJit (cx=cx@entry=0xf791d000, state=..., code=0x3ee3e230 "=\031") at js/src/jit/Jit.cpp:106
[...]
#27 main (argc=5, argv=0xffffcdd4, envp=0xffffcdec) at js/src/shell/js.cpp:8891
eax	0x0	0
ebx	0xffffb468	-19352
ecx	0xf7da4864	-136689564
edx	0x0	0
esi	0xffffb708	-18680
edi	0xf4240	1000000
ebp	0xffffb4a8	4294948008
esp	0xffffb420	4294947872
eip	0x8ad0cea <js::jit::BacktrackingAllocator::processBundle(js::jit::MIRGenerator*, js::jit::LiveBundle*)+810>
=> 0x8ad0cea <js::jit::BacktrackingAllocator::processBundle(js::jit::MIRGenerator*, js::jit::LiveBundle*)+810>:	movl   $0x0,0x0
   0x8ad0cf4 <js::jit::BacktrackingAllocator::processBundle(js::jit::MIRGenerator*, js::jit::LiveBundle*)+820>:	ud2

Comment 1

[Jason Orendorff [:jorendorff]]

Sean, can you take a look?

Comment 2

[Sean Stangl [:sstangl]]

I'm not familiar with the register allocator. Maybe bhackett can take a look? It reproduces reliably.

Comment 3

[Brian Hackett [Laid off!]]

Is there a blame cset?  This assertion usually indicates a lowering issue.

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/82bdb5c8e75d
user:        Tom Schuster
date:        Wed Oct 18 20:47:29 2017 +0200
summary:     Bug 1378186 - Implement super.property in Ion. r=jandem

Tom, is bug 1378186 a likely regressor?

Comment 5

[Tom S. (please needinfo tschuster)]

GetElem_Super requires a lot of registers: 1 for object, 1/2 receiver, 1/2 id, 2 output? I think this probably just regalloc issue.

Comment 6

[Brian Hackett [Laid off!]]

(In reply to Tom Schuster [:evilpie] from comment #5)
> GetElem_Super requires a lot of registers: 1 for object, 1/2 receiver, 1/2
> id, 2 output? I think this probably just regalloc issue.

x86 normally has seven allocatable registers, so this would be OK.  However, when profiling is enabled the regalloc cannot touch the frame pointer register and only six registers are available, making this instruction impossible for the regalloc to allocate.

Comment 7

[Jan de Mooij [:jandem]]

(In reply to Tom Schuster [:evilpie] from comment #5)
> GetElem_Super requires a lot of registers: 1 for object, 1/2 receiver, 1/2
> id, 2 output? I think this probably just regalloc issue.

x86 sucks, but maybe we can only optimize if the receiver is definitely an object, or something?

Comment 8

[Jan de Mooij [:jandem]]

Or maybe we could be smarter with the output register and use{Register,Box}AtStart for the operands...

Comment 9

[Tom S. (please needinfo tschuster)]

Attachment: Disable scripts with GETELEM_SUPER on x86 when profiling

This is short of a hack, but I think it's targeted enough that it shouldn't cause problems and is simple enough to uplift. Can somebody please actually try this on x86? My cross-compile setup is busted.

Comment 10

[Tom S. (please needinfo tschuster)]

x86 try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6ef59cfe18c9186132357c1fee901b0fd3cf2976

Comment 11

[Firefox Bug Husbandry Bot]

https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Move_fix-optionals

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/583fd2e84a45
Disable scripts with GETELEM_SUPER on x86 when profiling. r=jandem

Comment 13

[Tiberius Oros[:tiberius_oros]]

https://hg.mozilla.org/mozilla-central/rev/583fd2e84a45