RESOLVED DUPLICATE of bug 141174 139524
DFGAbstractInterpreter ASSERT loading nytimes.com with Web Inspector open
https://bugs.webkit.org/show_bug.cgi?id=139524
Summary DFGAbstractInterpreter ASSERT loading nytimes.com with Web Inspector open
Joseph Pecoraro
Reported 2014-12-10 19:08:08 PST
* STEPS TO REPRODUCE 1. Inspect about:blank 2. Navigate to http://nytimes.com => ASSERT ASSERTION FAILED: mayHaveTypeCheck(edge.useKind()) || !needsTypeCheck(edge) /Users/pecoraro/Code/safari/OpenSource/Source/JavaScriptCore/dfg/DFGAbstractInterpreter.h(102) : void JSC::DFG::AbstractInterpreter<JSC::DFG::InPlaceAbstractState>::filterEdgeByUse(JSC::DFG::Edge &) [AbstractStateType = JSC::DFG::InPlaceAbstractState] 1 0x119c5db40 WTFCrash 2 0x1194e04d9 JSC::DFG::AbstractInterpreter<JSC::DFG::InPlaceAbstractState>::filterEdgeByUse(JSC::DFG::Edge&) 3 0x1194e0451 JSC::DFG::AbstractInterpreter<JSC::DFG::InPlaceAbstractState>::filterEdgeByUse(JSC::DFG::Node*, JSC::DFG::Edge&) 4 0x1194cff39 JSC::DFG::AbstractInterpreter<JSC::DFG::InPlaceAbstractState>::executeEdges(JSC::DFG::Node*) 5 0x1194cf6cb JSC::DFG::AbstractInterpreter<JSC::DFG::InPlaceAbstractState>::execute(unsigned int) 6 0x1194cea24 JSC::DFG::CFAPhase::performBlockCFA(JSC::DFG::BasicBlock*) 7 0x1194ce5a7 JSC::DFG::CFAPhase::performForwardCFA() 8 0x1194ce376 JSC::DFG::CFAPhase::run() 9 0x1194ce045 bool JSC::DFG::runAndLog<JSC::DFG::CFAPhase>(JSC::DFG::CFAPhase&) 10 0x1194cdfce bool JSC::DFG::runPhase<JSC::DFG::CFAPhase>(JSC::DFG::Graph&) 11 0x1194cdf88 JSC::DFG::performCFA(JSC::DFG::Graph&) 12 0x119623690 JSC::DFG::Plan::compileInThreadImpl(JSC::DFG::LongLivedState&) 13 0x119622931 JSC::DFG::Plan::compileInThread(JSC::DFG::LongLivedState&, JSC::DFG::ThreadData*) 14 0x1196ee580 JSC::DFG::Worklist::runThread(JSC::DFG::ThreadData*) 15 0x1196ecb64 JSC::DFG::Worklist::threadFunction(void*) 16 0x119cb2419 WTF::createThread(void (*)(void*), void*, char const*)::$_0::operator()() const 17 0x119cb23ec std::__1::__function::__func<WTF::createThread(void (*)(void*), void*, char const*)::$_0, std::__1::allocator<WTF::createThread(void (*)(void*), void*, char const*)::$_0>, void ()>::operator()() 18 0x119c0de9a std::__1::function<void ()>::operator()() const 19 0x119cb136e WTF::threadEntryPoint(void*) 20 0x119cb2d78 WTF::wtfThreadEntryPoint(void*) 21 0x7fff8c6f5268 _pthread_body 22 0x7fff8c6f51e5 _pthread_body 23 0x7fff8c6f341d thread_start
Attachments
Joseph Pecoraro
Comment 1 2014-12-10 19:09:52 PST
Reproduced 3 out of 3 times for me. Debug builds @ r177108.
Radar WebKit Bug Importer
Comment 2 2014-12-17 11:21:40 PST
Mark Lam
Comment 3 2014-12-19 12:17:34 PST
The edge being in the assertion checked points to the LexicalEnvironment in a local var. However, our code current pretends that the LexicalEnvironment in a local var is a captured variable. During the DFG's CFA (control flow analysis) phase, the handler for PutClosureVars clobbers all the captured vars (including the LexicalEnvironment var) to clear any prediction of their expected types. This results in the type expectation mismatch that we triggered this assertion failure. The fix is to stop pretending that the LexicalEnvironment is a captured var. Will track the fix in <https://webkit.org/b/139827> because it involves many steps.
Mark Lam
Comment 4 2015-04-13 13:10:07 PDT
This issue no longer manifests because the root cause has been removed when the fix for https://bugs.webkit.org/show_bug.cgi?id=141174 landed. Resolving as a dup. *** This bug has been marked as a duplicate of bug 141174 ***
Note You need to log in before you can comment on or make changes to this bug.