Bug 136391 – ASSERTION FAILED: cell->isObject() in JSC::asObject(JSCell*)

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

[Akos Kiss]

When running tests on EFL/ARM64 (compiled with gcc), jsc segfaults on 451 tests with "ASSERTION FAILED: cell->isObject()". The simplest test case to cause the assertion is:

var o = {}
o = {__proto__: o}

The backtrace is as follows:

Program received signal SIGSEGV, Segmentation fault.
0x0000000001096b00 in WTFCrash () at /home/akiss/devel/WebKit/Source/WTF/wtf/Assertions.cpp:329
329	    *(int *)(uintptr_t)0xbbadbeef = 0;
(gdb) bt
#0  0x0000000001096b00 in WTFCrash ()
    at /home/akiss/devel/WebKit/Source/WTF/wtf/Assertions.cpp:329
#1  0x0000000000ae4fcc in JSC::asObject (cell=0x7fffffe660)
    at /home/akiss/devel/WebKit/Source/JavaScriptCore/runtime/JSObject.h:1189
#2  0x0000000000ae4ff4 in JSC::asObject (value=...)
    at /home/akiss/devel/WebKit/Source/JavaScriptCore/runtime/JSObject.h:1195
#3  0x0000000000be0900 in JSC::Register::function (this=0x7fffffe080)
    at /home/akiss/devel/WebKit/Source/JavaScriptCore/runtime/JSObject.h:1472
#4  0x0000000000be01b4 in JSC::ExecState::callee (this=0x7fffffe060)
    at /home/akiss/devel/WebKit/Source/JavaScriptCore/interpreter/CallFrame.h:46
#5  0x0000000000be9d44 in JSC::StackVisitor::readNonInlinedFrame (this=0x7fffffdf50, 
    callFrame=0x7fffffe060, codeOrigin=0x0)
    at /home/akiss/devel/WebKit/Source/JavaScriptCore/interpreter/StackVisitor.cpp:123
#6  0x0000000000be9bf0 in JSC::StackVisitor::readFrame (this=0x7fffffdf50, callFrame=0x7fffffe060)
    at /home/akiss/devel/WebKit/Source/JavaScriptCore/interpreter/StackVisitor.cpp:93
#7  0x0000000000be9b68 in JSC::StackVisitor::gotoNextFrame (this=0x7fffffdf50)
    at /home/akiss/devel/WebKit/Source/JavaScriptCore/interpreter/StackVisitor.cpp:68
#8  0x0000000000d77064 in JSC::StackVisitor::visit<JSC::GlobalFuncProtoSetterFunctor> (
    startFrame=0x7fffffe030, functor=...)
    at /home/akiss/devel/WebKit/Source/JavaScriptCore/interpreter/StackVisitor.h:132
#9  0x0000000000d7641c in JSC::ExecState::iterate<JSC::GlobalFuncProtoSetterFunctor> (
    this=0x7fffffe030, functor=...)
    at /home/akiss/devel/WebKit/Source/JavaScriptCore/interpreter/CallFrame.h:260
#10 0x0000000000d72f9c in JSC::globalFuncProtoSetter (exec=0x7fffffe030)
    at /home/akiss/devel/WebKit/Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp:793
#11 0x0000000000e8690c in vmEntryToNative ()

It seems that the root of the problem is that vmEntryToNative does not set up the CallerFrame component of exec for JSC::globalFuncProtoSetter properly. This is very similar to the problem of https://bugs.webkit.org/show_bug.cgi?id=136313 . Currently, we rely on the called function (JSC::globalFuncProtoSetter, in this case) to push fp to the right place, but arm64/gcc generates different (but still eabi-conformant) prologue.

[Akos Kiss]

Created attachment 237381 [details]
Proposed patch.

[Michael Saboff]

Comment on attachment 237381 [details]
Proposed patch.

r-

This should only be needed for calls from vmEntryToNative to native code.  Move the "storep cfr, [sp]" outside of the various if block to always happen in the makeHostFunctionCall macros in both LowLevelInterpreter{32_64,64}.asm

[Akos Kiss]

Created attachment 237388 [details]
Proposed patch, v2

[Michael Saboff]

Comment on attachment 237388 [details]
Proposed patch, v2

r=me

[WebKit Commit Bot]

Comment on attachment 237388 [details]
Proposed patch, v2

Clearing flags on attachment: 237388

Committed r173131: <http://trac.webkit.org/changeset/173131>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.