Closed Bug 771398 Opened 11 years ago Closed 11 years ago

IonMonkey: Crash at weird location of 0x08d966e8 with testcase and --no-jm


(Core :: JavaScript Engine, defect)

Other Branch
Not set



Tracking Status
firefox13 --- unaffected
firefox14 --- unaffected
firefox15 --- unaffected
firefox-esr10 --- unaffected


(Reporter: gkw, Assigned: dvander)



(Keywords: crash, sec-critical, testcase, Whiteboard: js-triage-needed)


(3 files, 1 obsolete file)

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
Attached file stack
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.
Assignee: general → dvander
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.
Attached patch fixSplinter Review
Carrying over r+ from where I accidentally posted this patch in bug 771200.
Attachment #642055 - Attachment is obsolete: true
Attachment #643146 - Flags: review+
Closed: 11 years ago
Resolution: --- → FIXED
Group: core-security
You need to log in before you can comment on or make changes to this bug.