The attached testcase crashes js opt shell on IonMonkey changeset 171cc91d4c18 with --no-jm at a weird memory address. I used gcc 4.6, and compiled with --enable-gczeal --enable-more-deterministic --enable-profiling but a lot of js folks couldn't reproduce. Nonetheless, filing anyway because I can reliably reproduce on my machine. Thanks go out to Sean, Marty and Bill for chipping in. It is suspected (not confirmed) that some form of weird interaction is going on in YARR and/or gc, so locking s-s

As one can see from the stack, a weird memory address of 0xfffffff8 is being accessed.

Ok, after looking at this for a couple of days with billm, this is what we believe is happening: the line that is gausing this looks like: foo.Replace(/foo/, "bar" + "baz"); and /foo/ is cloning/creating a RegExp object, the string concatenation is triggering a GC, which doesn't mark the regexp object because it only exists as an argument to the the call to Replace, not in any of the function's fixed stack slots. The GC pass frees the RexExpShared object that is pointed to by the RegExp argument, at which point the pointer in the argument RegExp object to the now invalid RegExpShared object never gets zeroed out. dvander said he would take this, since it is all sorts of tricky.

Still reproduces on my machine with IonMonkey changeset eb7a1a24077b with --no-jm on 32-bit opt shell, if that helps.

Thanks, Marty, for reducing this - the problem is exactly that form of expression. It's easy to see from the IR spew. /foo/ gets pushed onto the stack, and "bar + "baz" (being not effectful, but requiring a safepoint) GCs, and nothing scans the argument stack. We can fix this in other ways but it won't be safe for moving GC. So it's time to start scanning the argument space.

This unfortunately doesn't fix the reported crash, but it does fix the problem in comment #3. I'm still investigating.

Carrying over r+ from where I accidentally posted this patch in bug 771200.