RESOLVED WORKSFORME 123007
ASSERT at eyecon.ro/colorpicker/ with debugger enabled
https://bugs.webkit.org/show_bug.cgi?id=123007
Summary ASSERT at eyecon.ro/colorpicker/ with debugger enabled
Brian Burg
Reported 2013-10-17 17:38:09 PDT
Test case (debug build): 1. Open Web Inspector on any random page. 2. Navigate to http://www.eyecon.ro/colorpicker/ When the inner iframe commits the load of google ads, it seemingly detaches the debugger from the about:blank page. This causes a crash because ScriptDebugServer::m_currentCallFrame is set to non-zero garbage somehow (stale call frame?), so detach() will try to compare the passed global object to garbage. I have also seen a similar crash called through ~JSGlobalObject during a GC. Some logging output and a stack trace: WebCoreLoading google_ads_frame1: About to commit provisional load from previous URL 'about:blank' to new URL 'r20131015&cbv=r20130906&saldr=sa&correlator=1382055922461&frm=20&ga_vid=1759474066.1381969385&ga_sid=1382055921&ga_hid=803502688&ga_fc=1&u_tz=-420&u_his=2&u_java=1&u_h=1440&u_w=2560&u_ah=1418&u_aw=2556&u_cd=24&u_nplug=4&u_nmime=46&dff=arial&dfs=12&adx=228&ady=47&biw=1256&bih=810&oid=3&ref=http%3A%2F%2Fwww.google.com%2Furl%3Fsa%3Dt%26rct%3Dj%26q%3D%26esrc%3Ds%26source%3Dweb%26cd%3D1%26ved%3D0CCsQFjAA%26url%3Dhttp%253A%252F%252Fwww.eyecon.ro%252Fcolorpicker%252F%26ei%3DNi9fUoDQDJDMigLHgYHoDg%26usg%3DAFQjCNHzP6mhS3ZRqKiCwCYVGqVgA-D1ZA%26bvm%3Dbv.54176721%2Cd.cGE&vis=1&fu=0&ifi=1&pfi=48&dtd=2532&xpc=tOveq0U9uP&p=http%3A//www.eyecon.ro">http://googleads.g.doubleclick.net/pagead/ads?client=ca-pub-5673865389945635&output=html&h=90&slotname=2811626550&adk=2625878782&w=728&lmt=1382081122&flash=11.8.800&url=http%3A%2F%2Fwww.eyecon.ro%2Fcolorpicker%2F&dt=1382055920501&bpp=51&shv=r20131015&cbv=r20130906&saldr=sa&correlator=1382055922461&frm=20&ga_vid=1759474066.1381969385&ga_sid=1382055921&ga_hid=803502688&ga_fc=1&u_tz=-420&u_his=2&u_java=1&u_h=1440&u_w=2560&u_ah=1418&u_aw=2556&u_cd=24&u_nplug=4&u_nmime=46&dff=arial&dfs=12&adx=228&ady=47&biw=1256&bih=810&oid=3&ref=http%3A%2F%2Fwww.google.com%2Furl%3Fsa%3Dt%26rct%3Dj%26q%3D%26esrc%3Ds%26source%3Dweb%26cd%3D1%26ved%3D0CCsQFjAA%26url%3Dhttp%253A%252F%252Fwww.eyecon.ro%252Fcolorpicker%252F%26ei%3DNi9fUoDQDJDMigLHgYHoDg%26usg%3DAFQjCNHzP6mhS3ZRqKiCwCYVGqVgA-D1ZA%26bvm%3Dbv.54176721%2Cd.cGE&vis=1&fu=0&ifi=1&pfi=48&dtd=2532&xpc=tOveq0U9uP&p=http%3A//www.eyecon.ro' WebCoreHistory: Updating History for commit in frame WebCoreHistory: Updating History for redirect load in frame WebCoreLoading google_ads_frame1: Finished committing provisional load to URL about:blank ASSERTION FAILED: from.isCell() && from.asCell()->JSCell::inherits(std::remove_pointer<To>::type::info()) /Users/burg/repos/timelapse/WebKitBuild/Debug/JavaScriptCore.framework/PrivateHeaders/JSCell.h(187) : To JSC::jsCast(JSC::JSValue) [To = JSC::JSScope *] 1 0x10a041270 WTFCrash 2 0x10b0bf75f JSC::JSScope* JSC::jsCast<JSC::JSScope*>(JSC::JSValue) 3 0x10b0bf6e2 JSC::Register::scope() const 4 0x10b0bf5c5 JSC::ExecState::scope() const 5 0x10b0bf585 JSC::ExecState::lexicalGlobalObject() const 6 0x10b0cba49 JSC::ExecState::dynamicGlobalObject() 7 0x10c5b4ba3 WebCore::ScriptDebugServer::detach(JSC::JSGlobalObject*) 8 0x10c5a941c WebCore::ScriptController::attachDebugger(WebCore::JSDOMWindowShell*, JSC::Debugger*) 9 0x10c5a9224 WebCore::ScriptController::clearWindowShell(WebCore::DOMWindow*, bool) 10 0x10b69c16e WebCore::FrameLoader::clear(WebCore::Document*, bool, bool, bool) 11 0x10b48297f WebCore::DocumentWriter::begin(WebCore::URL const&, bool, WebCore::Document*) 12 0x10b452cfa WebCore::DocumentLoader::commitData(char const*, unsigned long) 13 0x1084973d0 WebKit::WebFrameLoaderClient::committedLoad(WebCore::DocumentLoader*, char const*, int) 14 0x10b454cc0 WebCore::DocumentLoader::commitLoad(char const*, int) 15 0x10b45529b WebCore::DocumentLoader::dataReceived(WebCore::CachedResource*, char const*, int) 16 0x10b0e0921 WebCore::CachedRawResource::notifyClientsDataWasReceived(char const*, unsigned int) 17 0x10b0e080e WebCore::CachedRawResource::addDataBuffer(WebCore::ResourceBuffer*) 18 0x10c7495be WebCore::SubresourceLoader::didReceiveDataOrBuffer(char const*, int, WTF::PassRefPtr<WebCore::SharedBuffer>, long long, WebCore::DataPayloadType) 19 0x10c7496eb WebCore::SubresourceLoader::didReceiveBuffer(WTF::PassRefPtr<WebCore::SharedBuffer>, long long, WebCore::DataPayloadType) 20 0x10c55e71c WebCore::ResourceLoader::didReceiveBuffer(WebCore::ResourceHandle*, WTF::PassRefPtr<WebCore::SharedBuffer>, int) 21 0x10c94aa29 -[WebCoreResourceHandleAsDelegate connection:didReceiveData:lengthReceived:]
Attachments
Mark Lam
Comment 1 2013-10-17 17:46:06 PDT
Funny. I was just investigating this issue today.
Alexey Proskuryakov
Comment 2 2013-10-18 09:46:32 PDT
Mark Lam
Comment 3 2013-10-21 15:10:25 PDT
In r157746: <http://trac.webkit.org/r157746> (https://bugs.webkit.org/show_bug.cgi?id=123084), I added code to nullify m_currentCallFrame when it can potentially become stale. With that change, I haven't been able to reproduce the issue on http://www.eyecon.ro/colorpicker/ anymore. That said, I still have not isolated the root cause as to why http://www.eyecon.ro/colorpicker/ is seeing an issue, and hence cannot say that we have a conclusive fix yet. I'll continue to investigate some more. Some data I have collected so far: 1. With http://www.eyecon.ro/colorpicker/, the ScriptDebugServer was getting returnEvent() callbacks just before detach() was called. 2. The last CallFrame passed to returnEvent() is the one that was in m_currentCallFrame. 3. Normally, we would expect the didExecuteProgram() callback to clean up m_currentCallFrame, but it was not called here. Then again, there wasn't a corresponding willExecuteProgram() that preceded it either. Note: this is not necessarily a bug, but I'm just noting an observation. 4. The assertion failed because the scope() in the CallFrame is 0 when we get to the detach(). Chances are the CallFrame* is already stale by that point. That's all I have for now. Still investigating.
Brian Burg
Comment 4 2013-10-21 16:39:57 PDT
I have seen the same debug assert on any page using google ads. So it is probably related to the particular iframe structure/frame navigations that their tracker performs.
Brian Burg
Comment 5 2013-11-18 08:33:15 PST
Seems to not be a problem any more.. did you fix this elsewhere?
Note You need to log in before you can comment on or make changes to this bug.