Bug 123007 – ASSERT at eyecon.ro/colorpicker/ with debugger enabled

• Component: JavaScriptCore
• Status: RESOLVED WORKSFORME

[Brian Burg]

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:]

[Mark Lam]

Funny.  I was just investigating this issue today.

[Alexey Proskuryakov]

<rdar://problem/15262920>

[Mark Lam]

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]

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]

Seems to not be a problem any more.. did you fix this elsewhere?