The following testcase crashes on mozilla-central built with --enable-exact-rooting --enable-gcgenerational, revision 8f08240128c8 (run with --fuzzing-safe --ion-eager): var gTestcases = new Array(); var gTc = gTestcases.length; function TestCase() gTestcases[gTc++] = this; function reportCompare () { new TestCase(); "x".match(/y/) } gczeal(7,1); reportCompare(); Array.prototype[1] = 2; reportCompare(); reportCompare(); reportCompare(); gTestcases[3].dump();

Crash trace: Program received signal SIGSEGV, Segmentation fault. compartment (this=0xf6900790) at /srv/repos/mozilla-central/js/src/vm/Interpreter.cpp:3862 3862 } #0 compartment (this=0xf6900790) at /srv/repos/mozilla-central/js/src/vm/Interpreter.cpp:3862 #1 check (obj=(JSObject *) 0xf6900790 Cannot access memory at address 0x2b2b2b2b, this=0xffffc718) at ../jscntxtinlines.h:72 #2 check (v=..., this=0xffffc718) at ../jscntxtinlines.h:87 #3 js::CompartmentChecker::check (this=0xffffc718, v=...) at ../jscntxtinlines.h:85 #4 0x08442368 in assertSameCompartmentDebugOnly<JS::MutableHandle<JS::Value> > (t1=<synthetic pointer>, cx=0x93873c8) at ../jscntxtinlines.h:154 #5 GetObjectElementOperation (res=$jsval(-nan(0xfff87f6900790)), rref=$jsval(-nan(0xfff8100000003)), wasObject=<optimized out>, objArg=(JSObject *) 0xf67381a0 [object Array], op=JSOP_GETELEM, cx=0x93873c8) at ../vm/Interpreter-inl.h:413 #6 GetElementOperation (res=..., rref=..., lref=..., op=<optimized out>, cx=<optimized out>) at ../vm/Interpreter-inl.h:465 #7 js::jit::DoGetElemFallback (cx=0x93873c8, frame=0xffffc7cc, stub=0x93bb338, lhs=$jsval(-nan(0xfff87f67381a0)), rhs=$jsval(-nan(0xfff8100000003)), res=$jsval(-nan(0xfff87f6900790))) at /srv/repos/mozilla-central/js/src/jit/BaselineIC.cpp:3894 eax 0x2b2b2b2b 724249387 => 0x80d6b94 <js::CompartmentChecker::check(JS::Value const&)+164>: mov (%eax),%eax This is now one of the most common fuzz signatures, so I suggest we start with that one :)

I haven't had enough linear, unobstructed time to get my head into this yet. What I did see makes me think this is going to be a complete beast to track down. Christian, if you have other reduced instances of this crash, it will be helpful to have them handy for triangulation. I'm unassigning myself in case Jon has some time to look at it tomorrow.

I have seen several other crashes with the same crash address pattern. One of these I filed as bug 924866 but I don't know if that's the same bug. Do you need more than those two? I have maybe 5 other crashes that all share two common things: 1) They somehow assign prototype or some index of it. 2) They crash at 0x2b2b2b2b but not always in the same function.

Yes please post the other crashes somewhere. Anything that would help to narrow this down would be great!

When I added the postbarrier to GenerateSetDenseElementIC in bug 919536, I messed up the assembly such that it didn't get called in the case when the write is to one beyond the last element in the array. Hence fuzz bugs like this and bug 924866.

Comment on attachment 816647 [details] [diff] [review] bug924864-fuzz-crash Review of attachment 816647 [details] [diff] [review]: ----------------------------------------------------------------- Yup. Glad I did not try to track this down myself. r=me