674511 - TI: Unstable crash on heap, likely GC related corruption

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

Attachment: Test case for shell (see README file inside).

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

Comment 1

[Brian Hackett [Laid off!]]

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.

Comment 2

[Christian Holler (:decoder)]

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".

Comment 3

[Brian Hackett [Laid off!]]

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