1404289 - Crash in js::jit::CFGAryControlInstruction<T>::getSuccessor

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P2)

Description

[baffclan]

This bug was filed from the Socorro interface and is 
report bp-39e66bb0-12c6-4c0a-a4ad-77eee0170929,
       bp-861792a1-a57f-4f34-8058-36e340170929.
=============================================================

Crashing Thread (12)
Frame 	Module 	Signature 	Source
0 	xul.dll 	js::jit::CFGAryControlInstruction<0>::getSuccessor(unsigned __int64) 	js/src/jit/IonControlFlow.h:199
1 	xul.dll 	js::jit::MAryControlInstruction<0, 1>::getUseFor(unsigned __int64) 	js/src/jit/MIR.h:3072
2 	xul.dll 	js::jit::ValueNumberer::discardDef(js::jit::MDefinition*) 	js/src/jit/ValueNumbering.cpp:362

Comment 1

[Naveed Ihsanullah [:naveed]]

Ted: low volume crash but worth a look/see

Comment 2

[Ted Campbell [:tcampbell]]

The CFGAryControlInstruction<0>::getSuccessor() virtual function overload is expected to always crash for this parameterization if called. The problem is that the |this| object at the time of crash has a vtable with the CFGAryControlInstruction<1>::getSuccessor() method which is legal to call. The code sequence that gets use here involves visitor pattern double-dispatch. Somehow we are loading the wrong value.

Some possibilities:
  - We have stack corruption and tried to pass an MIR object as the visitor LIRGenerator or ValueNumberer. This is possible since vtable data of different types is packed together so an invalid vtable[index] is very likely to still be a valid function pointer.
  - PGO bug. It is possible specialization optimizations screwed up.
  - Random corruption. This signature may just be more likely than average to be blamed for a bit flip due to the many vtable entries for it and easy-to-identify MOZ_CRASH.

I'm looking are more of these samples and checking if the generated code has any obvious vtable confusion.

Comment 3

[Ted Campbell [:tcampbell]]

I look at a few samples and they involve making a virtual method call on incorrect vtable. We land in MAryInstruction<0>::getOperand which is implemented to crash with this signature. There isn't enough data in these crashes to understand why the vtables are wrong. It is unclear if they are bitflips or memory overwrites.

One interesting crash is bp-c02bbea8-79ce-45dd-8b78-12dca0171009, which has a stack-allocated LIRGenerator get it's vtable replaced with that of the current object's vtable. They are of different types and we access some random vtable slot, leading to this crash. This is not a bit flip as I can see the two pointers (0x126C35B8 vs 0x12359028). It isn't clear how the stack got only the single slot corrupted by another objects vtable.

I'm not sure what is actionable here.

Comment 4

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

Closing because no crashes reported for 12 weeks.