923892 - Crash [@ getGeneric]

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

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

Attachment: stack

function f(code) {
    gc()
    eval(code)
}
f("\
    s0='';\
    a1=[];\
    a2=[];\
    for(v of a1) {\
        (function(){})\
    };\
    for(var x=0;x<63;++x) {\
        Array.prototype.push.call(a2,0)\
    }\
");
f("\
    Array.prototype.sort.call(a2,(function(){\
        for(v of s0) {\
            (function(){\
                c\
            })\
        }\
    }))\
")

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>

Comment 1

[Jon Coppeard (:jonco)]

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 ?? ()

Comment 2

[Terrence Cole [:terrence]]

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.

Comment 3

[Jon Coppeard (:jonco)]

It looks like the problem is a pointer to a JSString is being is being treated as a pointer to a JSObject here.

Comment 4

[Christian Holler (:decoder)]

Marked s-s based on comment 3.

Jonco, can this be exploited in some way?

Comment 5

[Terrence Cole [:terrence]]

Can we bisect to find a regressor? I'd guess the recent changes to array iterations are implicated, based on the stack.

Comment 6

[Daniel Veditz [:dveditz]]

> 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.

Comment 7

[Christian Holler (:decoder)]

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

Comment 8

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

(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.

Comment 9

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

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   http://hg.mozilla.org/mozilla-central/rev/48582b2df0af
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?

Comment 10

[Andrew McCreight [:mccr8]]

Marking sec-high per comment 3.

Comment 11

[Brian Hackett [Laid off!]]

Attachment: patch

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.

Comment 12

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/371ed1f8661f

Comment 13

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

This was landed recently on m-c:

http://hg.mozilla.org/mozilla-central/rev/371ed1f8661f

Comment 14

[David Chan [:dchan]]

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.

Comment 15

[Al Billings [:abillings - ex-MoCo]]

Marking Firefox 26 as unaffected based on regression date.