Bug 98722 – REGRESSION (r130359): Assertion failure in JSC::checkOffset caused by removal of fixed inline slots count assumption

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Mark Lam]

Change set <http://trac.webkit.org/changeset/130359> (https://bugs.webkit.org/show_bug.cgi?id=98332 Removed the assumption that "final" objects have a fixed number of inline slots) caused some mozilla  tests in run-javascriptcore-tests to fail intermittently when jsc is built with COLLECT_ON_EVERY_ALLOCATION enabled in heap/MarkedAllocator.cpp.  This issue does not manifest in r130344 which is the revision immediately before r130359 (as far as JavaScriptCore changes are concern).

I reproduced the issues by simply running the GC only one in 5 times in MarkedAllocator::allocateSlowCase() as follows (which runs a lot faster):
#if 1 // COLLECT_ON_EVERY_ALLOCATION // mlam
    static int count = 0;
    count = (count + 1) % 5;
    if (count == 0) {
        m_heap->collectAllGarbage();
        ASSERT(m_heap->m_operationInProgress == NoOperation);
    }
#endif

When I tried running an affected test in gdb, the test does not fail every time.  But if I re-run the test over and over again in gdb, it eventually fails with an assertion failure.  Here is an example backtrace from running the following (on a more recent build, r130716):

$ cd Source/JavaScriptCore/tests/mozilla
Source/JavaScriptCore/tests/mozilla$ DYLD_FRAMEWORK_PATH=/Volumes/Source/ws2/OpenSource/WebKitBuild/Debug/ gdb /Volumes/Source/ws2/OpenSource/WebKitBuild/Debug/jsc
...
(gdb) r -s  -f ./js1_6/shell.js -f ./js1_6/Array/shell.js -f ./js1_6/Array/regress-304828.js
Starting program: /Volumes/Source/ws2/OpenSource/WebKitBuild/Debug/jsc -s  -f ./js1_6/shell.js -f ./js1_6/Array/shell.js -f ./js1_6/Array/regress-304828.js
BUGNUMBER: 304828

STATUS: Array Generic Methods

ASSERTION FAILED: offset == invalidOffset || offset < inlineCapacity || isOutOfLineOffset(offset)
...

(gdb) bt
#0  0x00000001002433e7 in JSC::checkOffset (offset=37, inlineCapacity=13) at PropertyOffset.h:71
#1  0x00000001002b7209 in JSC::validateOffset (offset=37, inlineCapacity=13) at PropertyOffset.h:84
#2  0x00000001002b6f6e in JSC::JSObject::offsetForLocation (this=0x101dcffe0, location=0x101dd0118) at JSObject.h:468
#3  0x000000010032869d in JSC::setUpStaticFunctionSlot (exec=0x104800058, entry=0x102802060, thisObj=0x101dcffe0, propertyName={m_impl = 0x101902630, static NotAnIndex = 4294967295}, slot=@0x7fff5fbfdbf8) at /Volumes/Source/ws2/OpenSource/Source/JavaScriptCore/runtime/Lookup.cpp:87
#4  0x000000010035729a in JSC::getStaticFunctionSlot<JSC::JSNonFinalObject> (exec=0x104800058, table=0x101901680, thisObj=0x101dcffe0, propertyName={m_impl = 0x101902630, static NotAnIndex = 4294967295}, slot=@0x7fff5fbfdbf8) at Lookup.h:294
#5  0x0000000100356089 in JSC::ObjectPrototype::getOwnPropertySlot (cell=0x101dcffe0, exec=0x104800058, propertyName={m_impl = 0x101902630, static NotAnIndex = 4294967295}, slot=@0x7fff5fbfdbf8) at /Volumes/Source/ws2/OpenSource/Source/JavaScriptCore/runtime/ObjectPrototype.cpp:82
#6  0x000000010008c2e6 in JSC::JSCell::fastGetOwnPropertySlot (this=0x101dcffe0, exec=0x104800058, propertyName={m_impl = 0x101902630, static NotAnIndex = 4294967295}, slot=@0x7fff5fbfdbf8) at JSObject.h:905
#7  0x000000010008c0b0 in JSC::JSObject::getPropertySlot (this=0x101dcfe20, exec=0x104800058, propertyName={m_impl = 0x101902630, static NotAnIndex = 4294967295}, slot=@0x7fff5fbfdbf8) at JSObject.h:930
#8  0x0000000100085518 in JSC::JSObject::get (this=0x101dcfe20, exec=0x104800058, propertyName={m_impl = 0x101902630, static NotAnIndex = 4294967295}) at JSObject.h:955
#9  0x00000001002db1a0 in callDefaultValueFunction (exec=0x104800058, object=0x101dcfe20, propertyName={m_impl = 0x101902630, static NotAnIndex = 4294967295}) at /Volumes/Source/ws2/OpenSource/Source/JavaScriptCore/runtime/JSObject.cpp:736
#10 0x00000001002d833d in JSC::JSObject::defaultValue (object=0x101dcfe20, exec=0x104800058, hint=JSC::NoPreference) at /Volumes/Source/ws2/OpenSource/Source/JavaScriptCore/runtime/JSObject.cpp:775
#11 0x00000001002a9dd4 in JSC::JSObject::toPrimitive (this=0x101dcfe20, exec=0x104800058, preferredType=JSC::NoPreference) at JSObject.h:1142
#12 0x00000001002a971f in JSC::JSCell::toPrimitive (this=0x101dcfe20, exec=0x104800058, preferredType=JSC::NoPreference) at /Volumes/Source/ws2/OpenSource/Source/JavaScriptCore/runtime/JSCell.cpp:140
#13 0x000000010012c038 in JSC::JSValue::toPrimitive (this=0x7fff5fbfdef8, exec=0x104800058, preferredType=JSC::NoPreference) at JSCell.h:264
#14 0x000000010035796b in JSC::jsAddSlowCase (callFrame=0x104800058, v1={u = {asInt64 = 4326227488, ptr = 0x101dcfe20, asBits = {payload = 31260192, tag = 1}}}, v2={u = {asInt64 = 4321181664, ptr = 0x1018fffe0, asBits = {payload = 26214368, tag = 1}}}) at /Volumes/Source/ws2/OpenSource/Source/JavaScriptCore/runtime/Operations.cpp:54
#15 0x000000010042b467 in llint_slow_path_add (exec=0x104800058, pc=0x1020193f8) at /Volumes/Source/ws2/OpenSource/Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:633
#16 0x00000001004362dc in llint_op_add ()
#17 0x000000010024bc14 in JSC::JITCode::execute (this=0x100efdd00, stack=0x1036090e0, callFrame=0x104800058, globalData=0x101007e00) at JITCode.h:134
#18 0x000000010024846b in JSC::Interpreter::execute (this=0x1036090c0, program=0x100efdce0, callFrame=0x1018cfb88, thisObj=0x1018efd80) at /Volumes/Source/ws2/OpenSource/Source/JavaScriptCore/interpreter/Interpreter.cpp:878
#19 0x000000010012885f in JSC::evaluate (exec=0x1018cfb88, source=@0x7fff5fbff770, thisValue={u = {asInt64 = 4320983424, ptr = 0x1018cf980, asBits = {payload = 26016128, tag = 1}}}, returnedException=0x7fff5fbff790) at /Volumes/Source/ws2/OpenSource/Source/JavaScriptCore/runtime/Completion.cpp:77
#20 0x00000001000087c9 in runWithScripts (globalObject=0x1018cf980, scripts=@0x7fff5fbff880, dump=false) at jsc.cpp:567
#21 0x0000000100008008 in jscmain (argc=8, argv=0x7fff5fbff910) at jsc.cpp:755
#22 0x0000000100007efe in main (argc=8, argv=0x7fff5fbff910) at jsc.cpp:530
(gdb)

[Mark Lam]

This is also causing a crash in the layout test: inspector/styles/import-pseudoclass-crash.html

[Mark Lam]

The inspector/styles/import-pseudoclass-crash.html  crash seems to be intermittent.  I'm not seeing it on the ews bots.

[Dominik Röttsches (drott)]

*** Bug 99356 has been marked as a duplicate of this bug. ***

[Dominik Röttsches (drott)]

*** Bug 98596 has been marked as a duplicate of this bug. ***

[Geoffrey Garen]

<rdar://problem/12518688>

[Geoffrey Garen]

I tried reproducing this @r131809, using the COLLECT_ON_EVERY_ALLOCATION change above:
    - run-javascriptcore-tests --debug: no crash
    - r -s  -f ./js1_6/shell.js -f ./js1_6/Array/shell.js -f ./js1_6/Array/regress-304828.js: no crash
    - r -s  -f ./js1_6/shell.js -f ./js1_6/Array/shell.js -f ./js1_6/Array/regress-304828.js....: no crash

[Geoffrey Garen]

I can reproduce this using run-javascriptcore-tests @r130359, on many sub-tests.

[Simon Fraser (smfr)]

Frequently seeing this while debugging facebook.

[Antti Koivisto]

Seems pretty frequent

http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK1%20(Tests)/r133207%20(2384)/results.html

[Chris Dumez]

This crash still occurs regularly on EFL EWS:
http://build.webkit.org/results/EFL%20Linux%2064-bit%20Debug/r133475%20(8160)/results.html
http://build.webkit.org/results/EFL%20Linux%2064-bit%20Debug/r133460%20(8156)/results.html

It makes it tough to keep the bots green since it affects random tests.

[Simon Fraser (smfr)]

Still happens:
http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK1%20(Tests)/r138081%20(3961)/fast/dom/gc-acid3-crash-log.txt

[Ryosuke Niwa]

inspector/extensions/extensions-panel.html and inspector/extensions/extensions-api.html crashed on this run:
http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK1%20(Tests)/r138709%20(4272)/results.html

fast/dom/gc-acid3.html and inspector/profiler/webgl/webgl-profiler-get-error.html crashed on this run:
http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK2%20(Tests)/r138709%20(5405)/results.html

[Ryosuke Niwa]

We’re constantly seeing this failure on bots:

http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK1%20(Tests)/r138762%20(4284)/results.html

http://build.webkit.org/results/Apple%20Lion%20Debug%20WK1%20(Tests)/r138761%20(5649)/results.html

[Ryosuke Niwa]

Here's another one:

http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK1%20(Tests)/r138776%20(4290)/results.html

[Ryosuke Niwa]

Another one: http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK1%20(Tests)/r138805%20(4304)/results.html

This bug is preventing us from making debug bots green.

[Geoffrey Garen]

Bug 106686 should fix most of these reports. A related bug remains in JSObject::offsetForLocation() (coming soon).

[Geoffrey Garen]

Bug 106692 removes JSObject::offsetForLocation().

[Geoffrey Garen]

I believe this issue is fixed; we'll reopen if more buildbot issues appear.

[Geoffrey Garen]

BTW, Phil is the one who diagnosed this bug.

[Ryosuke Niwa]

(In reply to comment #17)
> Bug 106692 removes JSObject::offsetForLocation().

Exciting!

(In reply to comment #19)
> BTW, Phil is the one who diagnosed this bug.

Thanks a lot for following up on this bug. I really hope this flaky crash goes away in the next cycle.