Bug 139524

Summary: DFGAbstractInterpreter ASSERT loading nytimes.com with Web Inspector open
Product: WebKit Reporter: Joseph Pecoraro <joepeck>
Component: JavaScriptCoreAssignee: Mark Lam <mark.lam>
Severity: Normal CC: ggaren, joepeck, mark.lam, msaboff, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 139827    
Bug Blocks:    

Description Joseph Pecoraro 2014-12-10 19:08:08 PST
1. Inspect about:blank
2. Navigate to http://nytimes.com

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
Comment 1 Joseph Pecoraro 2014-12-10 19:09:52 PST
Reproduced 3 out of 3 times for me. Debug builds @ r177108.
Comment 2 Radar WebKit Bug Importer 2014-12-17 11:21:40 PST
Comment 3 Mark Lam 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.
Comment 4 Mark Lam 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 ***