Closed Bug 674511 Opened 9 years ago Closed 9 years ago
TI: Unstable crash on heap, likely GC related corruption
The attached testcase crashes on TI revision 058032661e2f (See README for running instructions). This test is very fragile and does not crash on every run (10 runs should be sufficient though). The original testcase didn't crash reliably either and it switched between various GC related asserts as well. I was not able to make this test crash in valgrind, but in GDB: (gdb) bt #0 0x00007f7ad24693a0 in ?? () #1 0x00007f7ad2470578 in ?? () #2 0x0000000000000001 in ?? () #3 0x00007fff3bc7d5f0 in ?? () #4 0x0000000000000000 in ?? () (gdb) x /4i $pc 0x7f7ad24693a0: cmp %r11,0x8(%r12) 0x7f7ad24693a5: jne 0x7f7ad2469a92 0x7f7ad24693ab: mov 0x20(%r12),%r12 0x7f7ad24693b0: mov $0x7f7ad2200060,%r11 Involved registers: r11 0xb79ea0 12033696 r12 0x200000059 8589934681
There is no README in the archive. I can't get this to repro by running on main.js with -m -n or -m -n -a.
Sorry, I added the README later and didn't update the archive. The README contained: To run this test, use "js -j -m -n -a -f shell.js -f main.js".
Not a GC issue, but an analysis issue introduced by the last refactoring. The number of objects in a type set and the number of properties in a type object are now part of the flag fields of the type set / type object rather than separate uint32s. This saves 4 bytes for each of these, but also imposes a limit on how many objects can be in a type set (256) and how many properties can be in a type object (4096). We check this limit when adding entries to these two, and mark the set/object unknown if the limit is hit. The problem is that we mark the set/object unknown while it is an inconsistent state --- the hash table storing the objects/properties has been updated, but not the number of entries (from which the table's capacity is determined). When marking a global type object as unknown because thousands of properties had been added to it, this inconsistent state caused it to fail to find the type set containing constraints listening to changes in the object's flags (which were about to change). Those constraints weren't triggered, the relevant scripts weren't recompiled, and when that code ran again its dependencies had been violated and it crashed. The fragility may be because the violated dependency was because of a slots reallocation on a global object (the old slots pointer was baked into the not-recompiled code), and if the 'realloc' call on the global object's slots didn't actually relocate the slots then things would work fine. http://hg.mozilla.org/projects/jaegermonkey/rev/23dc255291ae
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.