The following testcase crashes on mozilla-central revision 64b497e6f593 (threadsafe build, run with --fuzzing-safe --ion-eager --thread-count=2 --ion-parallel-compile=on): var callStack = new Array(); function reportCompare (expected, actual, description) { if (expected != actual) { } var testcase = new TestCase( "unknown-test-name", description, expected, actual ); } function enterFunc (funcName) callStack.push(funcName); function exitFunc (funcName) { var lastFunc = callStack.pop(); reportCompare(funcName, lastFunc, "Test driver failure wrong exit function "); } enterFunc ('test'); function TestCase(n, d) { exitFunc ('test'); } new TestCase ( String(true << 1 < 1 < this ) , String('aBCdEfGHijKLmno'.match(/fghijk/i)) );

Sorry for the badly formatted test, I wanted to reformat it first but seems like I missed that part ;) Crash trace: Program received signal SIGSEGV, Segmentation fault. 0xf729c288 in ?? () #0 0xf729c288 in ?? () #1 0xf70128e8 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) eax 0xf6f3d5b0 -151792208 ebx 0x0 0 ecx 0xf701c0f0 -150880016 edx 0xf701c100 -150880000 esi 0x48 72 edi 0xf6f37170 -151817872 ebp 0xf70128e0 4144048352 esp 0xffff494c 4294920524 eip 0xf729c288 4146709128 => 0xf729c288: mov (%ebx),%edi 0xf729c28a: test $0x8,%esi Marking as a fuzzblocker because it generates hard to match signatures.

Brian, this is probably a regression from one of your recent changes. It looks like we inline exitFunc into TestCase, then we invalidate exitFunc but the off-thread compilation of TestCase is not invalidated. Reduced testcase, crashes with --ion-eager --ion-parallel-compile=on: --- with(this) {}; var callStack = ['test']; function reportCompare(actual) { with(this) {}; print(actual); TestCase(); } function exitFunc() { var lastFunc = callStack.pop(); reportCompare(lastFunc); } function TestCase() { exitFunc(); } TestCase(); ---

After bug 921902 we don't add the constraint which triggers invalidation of an IonScript when type sets in callees are invalidated until the compilation finally ends, so any type changes while the script is being worked on off thread won't trigger that invalidation. I thought this would be OK but it seems there are some places where we do depend on stack type sets being "correct" in some way. In this case the ArrayPopDense VM function requires that the Monitor() call it makes on undefined values actually trigger invalidation of the caller if the Ion script was not compiled to expect an undefined value there. This should be fixed by bug 925962.