WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Add attachment
proposed patch, testcase, etc.
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
<
rdar://problem/15262920
>
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.
Top of Page
Format For Printing
XML
Clone This Bug