[Webkit-unassigned] [Bug 136391] New: ASSERTION FAILED: cell->isObject() in JSC::asObject(JSCell*)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=136391

           Summary: ASSERTION FAILED: cell->isObject() in
                    JSC::asObject(JSCell*)
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: akiss at inf.u-szeged.hu
                CC: msaboff at apple.com


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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.