With scripted ICs applied, I get random crashes in Mochitests that I've narrowed down to be unrelated, perhaps exacerbated by different GC timings. This is fairly difficult to test case and get the test case to do the wrong thing, but I can observe the problem in the debugger. > function f(x, y) { > print(x[y]); > } > f({a:2, b:3, c:4, d:5}, "a"); > f({a:2, b:3, c:4, d:5}, "a"); > f({a:2, b:3, c:4, d:5}, "b"); > gczeal(2); > gc(); > gczeal(0); > f({a:2, b:3, c:4, d:5}, "c"); > f({a:2, b:3, c:4, d:5}, "c"); > f({a:2, b:3, c:4, d:5}, "d"); At the end of this script, the IC looks like: 0xf7fc5d78: mov edx,DWORD PTR [ecx+0xc] 0xf7fc5d7b: cmp edx,0xe2 0xf7fc5d81: jne 0xf7fc5f51 0xf7fc5d87: cmp edi,0x83443a0 0xf7fc5d8d: jne 0xf7fc60c0 The final instruction is the atom identity guard, which still points to a generated stub, now garbage memory.

For posterity, my mochitest GDB session crashed at test ~82,000 with no stack and an unreadable EIP. These were the steps to track down this bug: 1. Cast $ebx to JSStackFrame * 2. Print $1->script 3. Print $2->jit->inlineLength 4. Print $2->ncode 5. disas $4 $4+$3 6. Search spew for the invalid EIP 7. Recognize pattern as GETELEM (hole guard, string guard) 8. Recover IC index from slow jump 9. Print $2->pics[index]