The following testcase crashes on mozilla-central revision f9c2c266e7aa (run with --ion-eager): gczeal(2) var args = ""; var s = ""; for ( var i = 0; i < 2000; i++ ) { s += ","; } function splice_args () { args = (({arguments: true, reportCompare: false}).class); return Array.prototype.splice.apply(args, [0, 5]); } var O = [0, 1, 2, 3, 4, 5, 6, 7, 8, .83 ]; var A = splice_args.apply(undefined, O)

Debug and opt crash traces: ==39758== Invalid read of size 8 ==39758== at 0x4280F8: JSString::isAtom() const (String.h:375) ==39758== by 0x42BCCD: js::CompartmentChecker::check(JSString*) (jscntxtinlines.h:235) ==39758== by 0x42BD63: js::CompartmentChecker::check(JS::Value const&) (jscntxtinlines.h:243) ==39758== by 0x530B28: js::CompartmentChecker::check(JS::CallArgs const&) (jscntxtinlines.h:258) ==39758== by 0x549B3B: void js::assertSameCompartment<JS::CallArgs>(JSContext*, JS::CallArgs const&) (jscntxtinlines.h:302) ==39758== by 0x530BB5: js::CallJSNative(JSContext*, int (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (jscntxtinlines.h:363) ==39758== by 0x53A18C: js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (jsinterp.cpp:367) ==39758== by 0x4664FB: js::Invoke(JSContext*, js::InvokeArgsGuard&, js::MaybeConstruct) (jsinterp.h:109) ==39758== by 0x4D8D6E: js_fun_apply(JSContext*, unsigned int, JS::Value*) (jsfun.cpp:976) ==39758== by 0x403FB6E: ??? ==39758== by 0x883FA5: EnterIon(JSContext*, js::StackFrame*, void*) (Ion.cpp:1426) ==39758== by 0x884286: js::ion::Cannon(JSContext*, js::StackFrame*) (Ion.cpp:1464) ==39758== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==41043== Invalid read of size 8 ==41043== at 0x631009: js::gc::MarkKind(JSTracer*, void**, JSGCTraceKind) (Heap.h:989) ==41043== by 0x631A24: js::gc::MarkValueRootRange(JSTracer*, unsigned long, JS::Value*, char const*) (Marking.cpp:387) ==41043== by 0x5C00C8: js::StackSpace::mark(JSTracer*) (Marking.h:158) ==41043== by 0x47F175: _ZN2jsL11MarkRuntimeEP8JSTracerb.isra.278 (jsgc.cpp:2511) ==41043== by 0x486F9B: IncrementalCollectSlice(JSRuntime*, long, js::gcreason::Reason, js::JSGCInvocationKind) (jsgc.cpp:3351) ==41043== by 0x489954: GCCycle(JSRuntime*, bool, long, js::JSGCInvocationKind, js::gcreason::Reason) (jsgc.cpp:4452) ==41043== by 0x489CF8: _ZL7CollectP9JSRuntimeblN2js18JSGCInvocationKindENS1_8gcreason6ReasonE.part.323 (jsgc.cpp:4566) ==41043== by 0x50E6F1: js::PropertyTree::getChild(JSContext*, js::Shape*, unsigned int, js::StackShape const&) (jsgcinlines.h:449) ==41043== by 0x51C8AF: _ZN8JSObject16getChildPropertyEP9JSContextPN2js5ShapeERNS2_10StackShapeE.constprop.190 (jsscope.cpp:360) ==41043== by 0x51E757: JSObject::addPropertyInternal(JSContext*, long, int (*)(JSContext*, JS::Handle<JSObject*>, JS::Handle<long>, JS::MutableHandle<JS::Value>), int (*)(JSContext*, JS::Handle<JSObject*>, JS::Handle<long>, int, JS::MutableHandle<JS::Value>), unsigned int, unsigned int, unsigned int, int, js::Shape**, bool) (jsscope.cpp:538) ==41043== by 0x51FB2D: JSObject::putProperty(JSContext*, long, int (*)(JSContext*, JS::Handle<JSObject*>, JS::Handle<long>, JS::MutableHandle<JS::Value>), int (*)(JSContext*, JS::Handle<JSObject*>, JS::Handle<long>, int, JS::MutableHandle<JS::Value>), unsigned int, unsigned int, unsigned int, int) (jsscope.cpp:613) ==41043== by 0x4CF454: _ZN2js20DefineNativePropertyEP9JSContextN2JS6HandleIP8JSObjectEENS3_IlEENS3_INS2_5ValueEEEPFiS1_S6_S7_NS2_13MutableHandleIS8_EEEPFiS1_S6_S7_iSB_Ejjij.constprop.379 (jsobj.cpp:3986) ==41043== Address 0x0 is not stack'd, malloc'd or (recently) free'd S-s because the opt-build trace and the test seem to be GC-related.

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

JSBugMon: Fix Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first good revision is: changeset: 112379:2e888de576a8 parent: 112378:cecdb284a108 parent: 112304:f9c2c266e7aa user: Ehsan Akhgari date: Mon Nov 05 21:50:43 2012 -0500 summary: Merge mozilla-central into mozilla-inbound Not all ancestors of this changeset have been checked. Use bisect --extend to continue the bisection from the common ancestor, 358c9830d166. This iteration took 111.223 seconds to run. Oops! We didn't test rev cecdb284a108, a parent of the blamed revision! Let's do that now. We did not test rev cecdb284a108 because it is not a descendant of either f9c2c266e7aa or f4aeed115e54. Rev cecdb284a108: Updating... Compiling... Testing... [Uninteresting] It didn't crash. (0.493 seconds) good (not interesting) Bisect lied to us! Parent rev cecdb284a108 was also good! Perhaps we should expand the search to include the common ancestor of the blamed changeset's parents. The common ancestor of cecdb284a108 and f9c2c266e7aa is 358c9830d166. Rev 358c9830d166: Updating... Compiling... Testing... Exit status: CRASHED signal 11 (SIGSEGV) (2.923 seconds) bad (interesting) The following line is still under testing: Try setting -s to 358c9830d166, and -e to f4aeed115e54, and re-run autoBisect.

Marking sec-crit because it sounds like memory corruption.

Might be something on the call path... Sean, would you mind looking at this? We might just be baking in NULL somewhere and trying to trace it.

The bug no longer reproduces, as far back as Comment 2.

Note that I also cannot reproduce the crash on Linux x86_64 with revision f9c2c266e7aa, --ion-eager.

Closing this out since we can't repro all the way back to comment 2 and with all of the fixes since this was filed it doesn't surprise me that this is gone. All we have left to do is find the patch that fixed it, which we're having trouble doing (comment 3).