Bug 47718 - ASSERT in twitter.com with JIT disabled
Summary: ASSERT in twitter.com with JIT disabled
Status: RESOLVED DUPLICATE of bug 47107
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-15 03:32 PDT by Xan Lopez
Modified: 2011-06-14 19:05 PDT (History)
7 users (show)

See Also:


Attachments
twitterassert.diff (1.90 KB, patch)
2010-10-15 03:35 PDT, Xan Lopez
ddkilzer: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Xan Lopez 2010-10-15 03:32:46 PDT
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
Comment 1 Xan Lopez 2010-10-15 03:35:09 PDT
Created attachment 70847 [details]
twitterassert.diff

This seems to fix the problem.
Comment 2 Zoltan Herczeg 2010-10-18 01:17:23 PDT
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.
Comment 3 Oliver Hunt 2010-10-18 11:30:11 PDT
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?
Comment 4 David Kilzer (:ddkilzer) 2010-10-24 08:56:49 PDT
Comment on attachment 70847 [details]
twitterassert.diff

r- to add layout test.
Comment 5 Gavin Barraclough 2011-06-14 19:05:47 PDT

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