Bug 109852 – ASSERTION FAILED: !callFrame->hadException() on detik.com

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

[Alexey Proskuryakov]

Just opening http://www.detik.com and scrolling around a little very frequently results in an assertion failure:

ASSERTION FAILED: !callFrame->hadException()
/Users/ap/Safari/OpenSource/Source/JavaScriptCore/interpreter/Interpreter.cpp(999) : JSC::JSValue JSC::Interpreter::executeCall(CallFrame *, JSC::JSObject *, JSC::CallType, const JSC::CallData &, JSC::JSValue, const JSC::ArgList &)
1   0x10eeb3c39 JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&)
2   0x10ecc2ac2 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&)
3   0x1108f6ee2 WebCore::JSMainThreadExecState::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&)
4   0x1113c526f WebCore::ScheduledAction::executeFunctionInContext(JSC::JSGlobalObject*, JSC::JSValue, WebCore::ScriptExecutionContext*)
5   0x1113c4e53 WebCore::ScheduledAction::execute(WebCore::Document*)
6   0x1113c4c94 WebCore::ScheduledAction::execute(WebCore::ScriptExecutionContext*)
7   0x1102e5ae8 WebCore::DOMTimer::fired()

This blocks testing in bug 107228.

[Alexey Proskuryakov]

Possibly related to bug 109838.

[Cosmin Truta]

(In reply to comment #1)
> Possibly related to bug 109838.

I also think it's a dupe. As I run that bug's URL with Qt MiniBrowser, it randomly assert-fails either on !globalData.exception or !callFrame->hadException()

[Cosmin Truta]

Although I can't close this bug, I can confirm that it no longer crashes, after changeset 143104.

[Alexey Proskuryakov]

I can't confirm now, because the site always crashes with an assertion, d->m_defersLoading != defers.

[Yong Li]

(In reply to comment #4)
> I can't confirm now, because the site always crashes with an assertion, d->m_defersLoading != defers.

This usually means some JS activities were executed when page is being deferred.

I usually use this ASSERT to catch them

bool ScriptController::canExecuteScripts(ReasonForCallingCanExecuteScripts reason)
{
    ...
    if (!allowed && reason == AboutToExecuteScript)
        m_frame->loader()->client()->didNotAllowScript();
+    if (allowed && reason == AboutToExecuteScript && m_frame->page()->defersLoading())
+        CRASH();
    return allowed;
}

Both Bug 107453 and Bug 107954 can cause such issue

[Alexey Proskuryakov]

I filed bug 111902 about defersLoading assertion.

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