Closed Bug 923892 Opened 10 years ago Closed 10 years ago

Crash [@ getGeneric]


(Core :: JavaScript Engine: JIT, defect)

Not set



Tracking Status
firefox26 --- unaffected
firefox27 --- fixed
firefox-esr24 --- unaffected
b2g18 --- unaffected
b2g-v1.1hd --- unaffected
b2g-v1.2 --- unaffected


(Reporter: gkw, Assigned: bhackett1024)



(4 keywords, Whiteboard: [jsbugmon:][qa-])


(2 files)

Attached file stack
function f(code) {
    for(v of a1) {\
    for(var x=0;x<63;++x) {\,0)\
        for(v of s0) {\

intermittently crashes js opt shell (tested with a threadsafe deterministic 64-bit debug build) on m-c changeset b5d24ef1eb37 with --ion-parallel-compile=on --ion-eager at getGeneric

My configure options are:

sh ./configure --enable-optimize --disable-debug --enable-profiling --enable-gczeal --enable-debug-symbols --enable-methodjit --enable-type-inference --disable-tests --enable-more-deterministic --enable-exact-rooting --enable-gcgenerational --with-ccache --enable-threadsafe <other NSPR options>
This testcase causes a crash for me even in normal debug builds, without GGC:

Catchpoint 1 (signal SIGSEGV), js::EncapsulatedPtr<js::BaseShape, unsigned long>::get (this=0x8) at ../../gc/Barrier.h:287
287	in ../../gc/Barrier.h
(gdb) bt
#0  js::EncapsulatedPtr<js::BaseShape, unsigned long>::get (this=0x8) at ../../gc/Barrier.h:287
#1  0x0000000000423485 in js::Shape::base (this=0x8) at ../../vm/Shape.h:1142
#2  0x00000000004251cd in js::ObjectImpl::compartment (this=0x7ffff57239a0) at ../../vm/ObjectImpl.h:1175
#3  0x00000000004980f2 in js::CompartmentChecker::check (this=0x7fffffff9a48, obj=(JSObject *) 0x7ffff57239a0 Cannot access memory at address 0x8) at ../jscntxtinlines.h:72
#4  0x00000000004a7603 in js::CompartmentChecker::check (this=0x7fffffff9a48, v=...) at ../jscntxtinlines.h:87
#5  0x00000000006338e0 in js::assertSameCompartment<JS::Rooted<JS::Value> > (cx=0x1adeed0, t1=...) at ../jscntxtinlines.h:145
#6  0x0000000000716fb7 in JS_ArrayIterator (cx=0x1adeed0, argc=0, vp=0x7fffffff9b58) at /home/jon/work/rooting/js/src/jsapi.cpp:3904
#7  0x00007ffff7f792e9 in ?? ()
#8  0x00007fffffff9b70 in ?? ()
#9  0x00007fffffff9b30 in ?? ()
#10 0x0000000000000000 in ?? ()
No longer blocks: ggcfuzz
Summary: GenerationalGC: Crash [@ getGeneric] → Fuzz crash [@ getGeneric]
It must have regressed between 149706:1328ae9ac634 and b5d24ef1eb37. The hotel's wireless was not up for an |hg pull| and I was not able to reproduce on my local tip.
It looks like the problem is a pointer to a JSString is being is being treated as a pointer to a JSObject here.
Marked s-s based on comment 3.

Jonco, can this be exploited in some way?
Group: core-security
Can we bisect to find a regressor? I'd guess the recent changes to array iterations are implicated, based on the stack.
Whiteboard: [jsbugmon:update,bisect]
> No longer blocks: 877471

This may have turned out not to be a crash in GGC, but the dependency link helps us track the effectiveness of our fuzzers. Fuzz tests quite often find bugs outside the feature the are ostensibly testing.
Blocks: ggcfuzz
Whiteboard: [jsbugmon:update,bisect]
Whiteboard: [jsbugmon:update,bisect]
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:bisect]
JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.
(In reply to Christian Holler (:decoder) from comment #7)
> JSBugMon: Cannot process bug: Unable to automatically reproduce, please
> track manually.

I'll need to start a manual bisect running it using the "range" interestingness test that tries this intermittent testcase repeatedly before calling it "good" or "bad", putting it on my plate.
Flags: needinfo?(gary)
Flags: needinfo?(gary)
Keywords: regression
Whiteboard: [jsbugmon:bisect] → [jsbugmon:]
Flags: needinfo?(gary)
Summary: Fuzz crash [@ getGeneric] → Crash [@ getGeneric]
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
user:        Brian Hackett
date:        Thu Oct 03 21:44:13 2013 -0600
summary:     Bug 921902 - Separate generation and attaching of heap property type constraints, r=jandem.

Brian, is bug 921902 a likely regressor?
Blocks: 921902
Flags: needinfo?(gary) → needinfo?(bhackett1024)
Keywords: crash
Marking sec-high per comment 3.
Keywords: sec-high
Attached patch patchSplinter Review
Off thread compilations were not always being canceled on type changes to a script, due to an unnecessary check that is now incorrect --- there can be in progress compilations even if there are no compiler outputs, since the compiler outputs aren't created until the compilation finishes.  While we don't in general want to rely on stack type sets being 'correct' in any way for Ion code, the Ion optimization that elides argument type checks for direct Ion -> Ion calls does rely on this to some degree --- any IonScript must handle all types in the script's this/arguments type sets.
Assignee: general → bhackett1024
Attachment #815413 - Flags: review?(jdemooij)
Flags: needinfo?(bhackett1024)
Attachment #815413 - Flags: review?(jdemooij) → review+
This was landed recently on m-c:
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Flags: in-testsuite?
Keywords: verifyme
Cleaning up list of security bugs for b2g18. This bug doesn't need to be backported either due to it affecting a later version of Fx or another reason.
Keywords: verifyme
Whiteboard: [jsbugmon:] → [jsbugmon:][qa-]
Component: JavaScript Engine → JavaScript Engine: JIT
Marking Firefox 26 as unaffected based on regression date.
Group: core-security
You need to log in before you can comment on or make changes to this bug.