Bug 47718 – ASSERT in twitter.com with JIT disabled

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: JavaScriptCore

[Xan Lopez]

Program received signal SIGSEGV, Segmentation fault.
0x00d1e7a1 in JSC::JSValue::asCell (this=0xbfffbf90) at ../../JavaScriptCore/runtime/JSValue.h:572
572	        ASSERT(isCell());
(gdb) bt
#0  0x00d1e7a1 in JSC::JSValue::asCell (this=0xbfffbf90) at ../../JavaScriptCore/runtime/JSValue.h:572
#1  0x00d1fd6d in JSC::asObject (value=...) at ../../JavaScriptCore/runtime/JSObject.h:298
#2  0x01a0b879 in JSC::asActivation (value=...) at ../../JavaScriptCore/runtime/JSActivation.h:109
#3  0x01a04dc9 in JSC::Interpreter::privateExecute (this=0x8954d48, flag=JSC::Interpreter::Normal, registerFile=0x8954d54, callFrame=0xb6200338, 
    exception=0x895435c) at ../../JavaScriptCore/interpreter/Interpreter.cpp:4065
#4  0x019f6325 in JSC::Interpreter::executeCall (this=0x8954d48, callFrame=0x8972eec, function=0xb67518c0, callType=JSC::CallTypeJS, callData=..., 
    thisValue=..., args=..., exception=0x895435c) at ../../JavaScriptCore/interpreter/Interpreter.cpp:822
#5  0x01a5377f in JSC::call (exec=0x8972eec, functionObject=..., callType=JSC::CallTypeJS, callData=..., thisValue=..., args=...)
    at ../../JavaScriptCore/runtime/CallData.cpp:38
#6  0x00d2367a in WebCore::JSMainThreadExecState::call (exec=0x8972eec, functionObject=..., callType=JSC::CallTypeJS, callData=..., thisValue=..., args=...)
    at ../../WebCore/bindings/js/JSMainThreadExecState.h:48
#7  0x00d5e270 in WebCore::JSEventListener::handleEvent (this=0x896f728, scriptExecutionContext=0x89c9230, event=0x8a968c0)
    at ../../WebCore/bindings/js/JSEventListener.cpp:124
#8  0x00f145f4 in WebCore::EventTarget::fireEventListeners (this=0x89a8fc8, event=0x8a968c0, d=0x8a1abb0, entry=...)
    at ../../WebCore/dom/EventTarget.cpp:335
#9  0x00f144a5 in WebCore::EventTarget::fireEventListeners (this=0x89a8fc8, event=0x8a968c0) at ../../WebCore/dom/EventTarget.cpp:304
#10 0x00f27a21 in WebCore::Node::handleLocalEvents (this=0x89a8fc8, event=0x8a968c0) at ../../WebCore/dom/Node.cpp:2526
#11 0x00f281dc in WebCore::Node::dispatchGenericEvent (this=0x89a8fc8, prpEvent=...) at ../../WebCore/dom/Node.cpp:2644
#12 0x00f27ddb in WebCore::Node::dispatchEvent (this=0x89a8fc8, prpEvent=...) at ../../WebCore/dom/Node.cpp:2589
#13 0x01060ddd in WebCore::HTMLScriptElement::dispatchLoadEvent (this=0x89a8fc8) at ../../WebCore/html/HTMLScriptElement.cpp:189
#14 0x00f4cfaa in WebCore::ScriptElementData::execute (this=0x89a9010, cachedScript=0x8b0add0) at ../../WebCore/dom/ScriptElement.cpp:242
#15 0x00eaf0ca in WebCore::AsyncScriptRunner::timerFired (this=0x89bd130, timer=0x89bd140) at ../../WebCore/dom/AsyncScriptRunner.cpp:87
#16 0x00eafaf4 in WebCore::Timer<WebCore::AsyncScriptRunner>::fired (this=0x89bd140) at ../../WebCore/platform/Timer.h:98
#17 0x012d0413 in WebCore::ThreadTimers::sharedTimerFiredInternal (this=0x890fbb0) at ../../WebCore/platform/ThreadTimers.cpp:112
#18 0x012d035b in WebCore::ThreadTimers::sharedTimerFired () at ../../WebCore/platform/ThreadTimers.cpp:90
#19 0x015d4021 in WebCore::timeout_cb () at ../../WebCore/platform/gtk/SharedTimerGtk.cpp:49
#20 0x0425265b in g_timeout_dispatch (source=0x8d64348, callback=0x15d3ffd <WebCore::timeout_cb(gpointer)>, user_data=0x0) at gmain.c:3585
#21 0x0424f5f2 in g_main_dispatch (context=0x813ae40) at gmain.c:2149
#22 0x042508e6 in g_main_context_dispatch (context=0x813ae40) at gmain.c:2702
#23 0x04250d3b in g_main_context_iterate (context=0x813ae40, block=1, dispatch=1, self=0x8112f18) at gmain.c:2780
#24 0x042514a4 in g_main_loop_run (loop=0x816ab28) at gmain.c:2988
#25 0x03db5c57 in gtk_main () at gtkmain.c:1320
#26 0x0806d351 in main (argc=1, argv=0xbfffed74) at ../../src/ephy-main.c:741

[Xan Lopez]

Created attachment 70847 [details]
twitterassert.diff

This seems to fix the problem.

[Zoltan Herczeg]

Is there a test case for this?

        if (activationValue) {
            asActivation(activationValue)->copyRegisters();

            if (JSValue argumentsValue = callFrame->r(unmodifiedArgumentsRegister(arguments)).jsValue())
                asArguments(argumentsValue)->setActivation(asActivation(activationValue));
        } else if (JSValue argumentsValue = callFrame->r(unmodifiedArgumentsRegister(arguments)).jsValue())
            asArguments(argumentsValue)->copyRegisters();

        if (JSValue argumentsValue = callFrame->r(unmodifiedArgumentsRegister(arguments)).jsValue()) {
            if (!codeBlock->isStrictMode())
                asArguments(argumentsValue)->setActivation(asActivation(activationValue));
        }

The code is quite strange for me. I suspect the second "if" with argumentsValue should be totally removed since, the "if (activationValue)" already contains this if...

Oliver Hunt recently touched this code (one of his patch was titled "fix wrong merge"), maybe he can help you more.

[Oliver Hunt]

Comment on attachment 70847 [details]
twitterassert.diff

Whoops.  Can we get a test case with this or does the interpreter fail existing tests because of this?

[David Kilzer (:ddkilzer)]

Comment on attachment 70847 [details]
twitterassert.diff

r- to add layout test.

[Gavin Barraclough]

*** This bug has been marked as a duplicate of bug 47107 ***