Closed Bug 972364 Opened 7 years ago Closed 7 years ago

Crash [@ js::shadow::Object::numFixedSlots] with TypedObject

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla30
Tracking Status
firefox28 --- unaffected
firefox29 --- fixed
firefox30 --- fixed
firefox-esr24 --- unaffected

People

(Reporter: decoder, Assigned: nmatsakis)

References

Details

(Keywords: crash, sec-high, testcase, Whiteboard: [jsbugmon:])

Crash Data

Attachments

(1 file)

The following testcase crashes on mozilla-central revision a62bde1d6efe (threadsafe build, run with --fuzzing-safe --thread-count=2 --ion-check-thread-safety):


setJitCompilerOption("ion.usecount.trigger", 30);
var N2 = 150;
var T = TypedObject;
var Array2 = T.uint32.array(N2);
  var array2 = new Array2();
  for (var i = 0; i < N2; i++)
    array2[i] = i + 2;
Crash trace:


Program received signal SIGSEGV, Segmentation fault.
0x0000000000421914 in js::shadow::Object::numFixedSlots (this=0x7ffff6456be0) at js/src/shell/../jsfriendapi.h:575
575         size_t numFixedSlots() const { return shape->slotInfo >> Shape::FIXED_SLOTS_SHIFT; }
#0  0x0000000000421914 in js::shadow::Object::numFixedSlots (this=0x7ffff6456be0) at js/src/shell/../jsfriendapi.h:575
#1  0x0000000000422d96 in js::ObjectImpl::numFixedSlots (this=0x7ffff6456be0) at js/src/shell/../vm/ObjectImpl.h:1215
#2  0x0000000000a4f7bb in js::ObjectImpl::slotInRange (this=0x7ffff6456be0, slot=0, sentinel=js::ObjectImpl::SENTINEL_NOT_ALLOWED) at js/src/vm/ObjectImpl.cpp:298
#3  0x0000000000422e50 in js::ObjectImpl::getSlot (this=0x7ffff6456be0, slot=0) at js/src/shell/../vm/ObjectImpl.h:1320
#4  0x000000000044668e in JSObject::getReservedSlot (this=(const JSObject * const) 0x7ffff6456be0 [object ArrayType], index=0) at js/src/jsobj.h:435
#5  0x00000000005101ef in js::TypeDescr::typeRepresentationOwnerObj (this=(const js::TypeDescr * const) 0x7ffff6456be0 [object ArrayType]) at js/src/builtin/TypedObject.h:141
#6  0x00000000004cd69c in js::TypeDescr::typeRepresentation (this=(const js::TypeDescr * const) 0x7ffff6456be0 [object ArrayType]) at js/src/builtin/TypedObject.cpp:183
#7  0x00000000004cd6be in js::TypeDescr::kind (this=(const js::TypeDescr * const) 0x7ffff6456be0 [object ArrayType]) at js/src/builtin/TypedObject.cpp:188
rax     0xf6456be0      140737325132768
=> 0x421914 <js::shadow::Object::numFixedSlots() const+12>:     mov    (%rax),%rax


Looks like a harmful crash reading from some invalid address, marking sec-high for now.
Whiteboard: [jsbugmon:update,bisect]
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:bisect]
JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.
Please ignore some of the bug traffic following now, I'm adding support for threadsafe builds and binary bisection to JSBugMon, and this bug is perfect for reproducing on those configurations and recent enough :)
Whiteboard: [jsbugmon:bisect] → [jsbugmon:update,bisect]
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result:
=== Tinderbox Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20140211112907" and the hash "1a05d8dffc65".
The "bad" changeset has the timestamp "20140211114007" and the hash "2ab85f86868a".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1a05d8dffc65&tochange=2ab85f86868a
\o/ And now we'll test the compilation-based bisection.
Whiteboard: [jsbugmon:update] → [jsbugmon:update,bisect,bisect-force-compile]
Whiteboard: [jsbugmon:update,bisect,bisect-force-compile] → [jsbugmon:update]
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   http://hg.mozilla.org/mozilla-central/rev/182eee4ae305
user:        Nicholas D. Matsakis
date:        Tue Jan 28 18:24:23 2014 -0500
summary:     Bug 966575 part 04 -- Make TI Type Object Addendum refer to actual descriptor and not TypeRepresentation*

This iteration took 1.082 seconds to run.
I guess that's as successful as it could get :) Needinfo from :nmatsakis based on comment 7 :)
Flags: needinfo?(nmatsakis)
Assignee: nobody → nmatsakis
Flags: needinfo?(nmatsakis)
Whiteboard: [jsbugmon:update] → [jsbugmon:update,ignore]
JSBugMon: The testcase found in this bug no longer reproduces (tried revision 33b3248b4aa0).
Whiteboard: [jsbugmon:update,ignore] → [jsbugmon:bisectfix]
Whiteboard: [jsbugmon:bisectfix] → [jsbugmon:]
JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   http://hg.mozilla.org/mozilla-central/rev/8c521a802625
parent:      168757:9e7cf0b1d80c
user:        Jan de Mooij
date:        Fri Feb 14 13:17:53 2014 +0100
summary:     Backout bug 785905, off-thread IonBuilder. r=jorendorff

This iteration took 371.896 seconds to run.
So, I can't reproduce this, which seems to correspond to the bisection. Jan, do you think this was caused by bad commit for bug 785905?
Flags: needinfo?(jdemooij)
(In reply to Niko Matsakis [:nmatsakis] from comment #11)
> So, I can't reproduce this, which seems to correspond to the bisection. Jan,
> do you think this was caused by bad commit for bug 785905?

Yes, the testcase in comment 0 has --ion-check-thread-safety, that triggered segfaults when calling some non-thread-safe method like numFixedSlots() off-thread. With the backout of bug 785905 that flag is also gone and it's fine to call numFixedSlots() from IonBuilder.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(jdemooij)
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
JSBugMon: This bug has been automatically verified fixed.
Blocks: 785905
Target Milestone: --- → mozilla30
Group: core-security
You need to log in before you can comment on or make changes to this bug.