The following testcase crashes on mozilla-central revision 1b6ab3a080d8 (run with --ion-parallel-compile=on --thread-count=2 --ion-eager): function f(code) { a = code.replace(/s/, ""); code = code.replace(/\/\*DUPTRY\d+\*\//, function(k) { return g("Infinity/Math.sqrt", "-0", -Infinity) }); f = eval(0 && -0 ) if (typeof disassemble == 'function') { disassemble("-r", f) } } function g(s, n) { if (n == 0) { } s2 = s + s r = n % 2 d = (n - r) / 2 m = g(s2, d) return r ? m + s : m } f("switch(''){default:break;/*DUPTRY525*/}")

Requires a threadsafe build to reproduce and behaves non-deterministic (due to thread scheduling). Crash trace shows a possible use-after-free, marking appropriately (please correct rating if this is wrong: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffeffff700 (LWP 64606)] 0x00000000008a3b14 in js::ion::CountArgSlots (fun=(JSFunction *) 0xcdcdcdcdcdcdcdcd Cannot access memory at address 0xcdcdcdcdcdcdcdcd) at ../ion/CompileInfo.h:17 17 return fun ? fun->nargs + 2 : 1; // +2 for |scopeChain| and |this|, or +1 for |scopeChain| (gdb) bt #0 0x00000000008a3b14 in js::ion::CountArgSlots (fun=(JSFunction *) 0xcdcdcdcdcdcdcdcd Cannot access memory at address 0xcdcdcdcdcdcdcdcd) at ../ion/CompileInfo.h:17 #1 0x00000000008d4c6c in js::ion::CompileInfo::firstLocalSlot (this=0xf713c0) at /srv/repos/mozilla-central/js/src/ion/CompileInfo.h:131 #2 0x00000000008d4ca7 in js::ion::CompileInfo::firstStackSlot (this=0xf713c0) at /srv/repos/mozilla-central/js/src/ion/CompileInfo.h:137 #3 0x0000000000967dc9 in js::ion::MBasicBlock::MBasicBlock (this=0xfa97e8, graph=..., info=..., pc=0xf6eae8 "T", kind=js::ion::MBasicBlock::SPLIT_EDGE) at /srv/repos/mozilla-central/js/src/ion/MIRGraph.cpp:134 #4 0x0000000000967b13 in js::ion::MBasicBlock::New (graph=..., info=..., pred=0xfa41f8, entryPc=0xf6eae8 "T", kind=js::ion::MBasicBlock::SPLIT_EDGE) at /srv/repos/mozilla-central/js/src/ion/MIRGraph.cpp:74 #5 0x0000000000967d1b in js::ion::MBasicBlock::NewSplitEdge (graph=..., info=..., pred=0xfa41f8) at /srv/repos/mozilla-central/js/src/ion/MIRGraph.cpp:127 #6 0x00000000008c00f1 in js::ion::SplitCriticalEdges (graph=...) at /srv/repos/mozilla-central/js/src/ion/IonAnalysis.cpp:31 #7 0x00000000008b06f3 in js::ion::CompileBackEnd (mir=0xfa11a8) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:795 #8 0x0000000000685daa in js::WorkerThread::threadLoop (this=0xf9f610) at /srv/repos/mozilla-central/js/src/jsworkers.cpp:327 #9 0x0000000000685b92 in js::WorkerThread::ThreadMain (arg=0xf9f610) at /srv/repos/mozilla-central/js/src/jsworkers.cpp:295 #10 0x00007ffff79a2e99 in _pt_root (arg=0xf965e0) at ptthread.c:156 #11 0x00007ffff7bc4e9a in start_thread (arg=0x7fffeffff700) at pthread_create.c:308 #12 0x00007ffff6e8ccbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #13 0x0000000000000000 in ?? () (gdb) x /i $pc => 0x8a3b14 <js::ion::CountArgSlots(JSFunction*)+19>: movzwl 0x20(%rax),%eax (gdb) info reg rax rax 0xcdcdcdcdcdcdcdcd -3617008641903833651 Chances to reproduce this issue are around 1-10% of all runs.

Via IRC: 15:04 < sstangl> bhackett: my current guess is that block->info() uses LifoAlloc. The RegExp engine also uses LifoAlloc in order to store MatchPairs. If a compilation occurs after the MatchPairs are created, and then the MatchPairs are destroyed first, the LifoAlloc stack will be overwritten with 0xcd..cd up to the mark 15:04 < sstangl> which I interpret as meaning that it is wrong for compilation to use the same LifoAlloc as the VM

fix checked into inbound in bug 822145. Since this bug has a definite testcase I'd prefer marking this "fixed" so it can be verified, unlike bug 822145 which can only be statistically assumed to have fixed the right issue.

Although the crash spike in bug 822145 appears to be a more recent regression from a YARR change (bug 808245) the actual patch is to IonBuilder code that looks like it goes back to the Ion landing (with a minor change in Nov). Is there potentially some other way to trigger the problem in Firefox 18 or 19 builds such that we'd need to land this fix on those branches?

I guess if this requires parallel compilation then it can't affect normal users prior to bug 813559, in which case we don't need it on 18 or 19.