758167 - IonMonkey: Crash [@ js::EncapsulatedPtr<JSObject, unsigned int>::operator]

Status: RESOLVED DUPLICATE of bug 768004

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on ionmonkey revision 407632130d1b (run with --ion -n -m --ion-eager):


gczeal(2); 
function complex(aReal, aImag) {
  this.r = aReal;
  this.i = aImag;
  this.square = function() {
    return new complex(this.r * this.r - this.i * this.i, 2 * this.r * this.i);
  }
  this.add = function(aComplex) {
    return new complex(this.r + aComplex.r, this.i + aComplex.i);
  }
}
function mandelbrotValueOO (aC, aIterMax) {
  let Z = new complex(0.0, 0.0);
  Z = Z.square().add(aC);
}
const width = 60;
const height = 60;
const max_iters = 50;
for (let img_x = 0; img_x < width; img_x++) {
  for (let img_y = 0; img_y < height; img_y++) {
    let C = new complex(-2 + (img_x / width) * 3, -1.5 + (img_y / height) * 3);
    var res = mandelbrotValueOO(C, max_iters);
  }
}

Comment 1

[Christian Holler (:decoder)]

Just noticed that there is no crash trace here. Here we go (taken on 4ce3983a43f4):


==31233== Invalid read of size 4
==31233==    at 0x805C24A: js::EncapsulatedPtr<JSObject, unsigned int>::operator JSObject*() const (Barrier.h:172)
==31233==    by 0x806CFB6: js::ObjectImpl::hasSingletonType() const (ObjectImpl.h:1057)
==31233==    by 0x80A093A: js::types::Type::ObjectType(JSObject*) (jsinferinlines.h:34)
==31233==    by 0x80A0A09: js::types::GetValueType(JSContext*, JS::Value const&) (jsinferinlines.h:60)
==31233==    by 0x81327CD: js::types::TypeMonitorResult(JSContext*, JSScript*, unsigned char*, JS::Value const&) (jsinfer.cpp:4965)
==31233==    by 0x81452D8: js::types::TypeScript::Monitor(JSContext*, JSScript*, unsigned char*, JS::Value const&) (jsinferinlines.h:590)
==31233==    by 0x8404011: js::ion::ReflowTypeInfo(unsigned int) (Bailouts.cpp:477)
==31233==    by 0x979E3E0: ???
==31233==  Address 0xdadadade is not stack'd, malloc'd or (recently) free'd

Comment 2

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision c4ba8fc5a1d0).

Comment 3

[Jan de Mooij [:jandem]]

I can still reproduce this at revision c4ba8fc5a1d0 with --ion-eager --no-jm.

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

This bug is: yuck. We bail out in the prologue and assume the pc (which is the first pc) is something that already ran.

Comment 5

[David Anderson [:dvander] - inactive, e-mail if emergency]

Struggling to find a non-terrible solution here. Having a prologue opcode would do the trick. Another option is, in InvalidationBailout, only monitoring types if it's a "resume-after" bailout.

Comment 6

[Jan de Mooij [:jandem]]

(In reply to David Anderson [:dvander] from comment #5)
> Another option is, in InvalidationBailout, only
> monitoring types if it's a "resume-after" bailout.

I did this in bug 768004 to fix a similar bug and I can no longer reproduce this crash.