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>

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

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?

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

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

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.

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?

Marking sec-high per comment 3.

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.

This was landed recently on m-c: http://hg.mozilla.org/mozilla-central/rev/371ed1f8661f

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.

Marking Firefox 26 as unaffected based on regression date.