Bug 109852
| Summary: | ASSERTION FAILED: !callFrame->hadException() on detik.com | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Alexey Proskuryakov <ap> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | ctruta, fpizlo, ggaren, oliver, yong.li.webkit |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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 ***