Bug 16871 – Crash when loading apple.com/startpage

• Component: JavaScriptCore
• Status: RESOLVED WORKSFORME

[Adam Roben (:aroben)]

I'm seeing the following crash with r29467 when loading <http://www.apple.com/startpage> (my home page):

First-chance exception at 0x014bea10 (WebKit_debug.dll) in Safari_debug.exe: 0xC0000005: Access violation reading location 0x00000028.

>	WebKit_debug.dll!KJS::JSValue::toObject(KJS::ExecState * exec=0x0012f0bc)  Line 462 + 0x41 bytes	C++
 	WebKit_debug.dll!KJS::DotAccessorNode::inlineEvaluate(KJS::ExecState * exec=0x0012f0bc)  Line 814 + 0x17 bytes	C++
 	WebKit_debug.dll!KJS::DotAccessorNode::evaluate(KJS::ExecState * exec=0x0012f0bc)  Line 820	C++
 	WebKit_debug.dll!KJS::LessNode::inlineEvaluateToBoolean(KJS::ExecState * exec=0x0012f0bc)  Line 2564 + 0x21 bytes	C++
 	WebKit_debug.dll!KJS::LessNode::evaluateToBoolean(KJS::ExecState * exec=0x0012f0bc)  Line 2577	C++
 	WebKit_debug.dll!KJS::ForNode::execute(KJS::ExecState * exec=0x0012f0bc)  Line 3801 + 0x21 bytes	C++
 	WebKit_debug.dll!KJS::statementListExecute(WTF::Vector<WTF::RefPtr<KJS::StatementNode>,0> & statements={...}, KJS::ExecState * exec=0x0012f0bc)  Line 3593 + 0x29 bytes	C++
 	WebKit_debug.dll!KJS::BlockNode::execute(KJS::ExecState * exec=0x0012f0bc)  Line 3618 + 0x10 bytes	C++
 	WebKit_debug.dll!KJS::FunctionBodyNode::execute(KJS::ExecState * exec=0x0012f0bc)  Line 4520	C++
 	WebKit_debug.dll!KJS::FunctionImp::callAsFunction(KJS::ExecState * exec=0x0012f390, KJS::JSObject * thisObj=0x05e00000, const KJS::List & args={...})  Line 76 + 0x21 bytes	C++
 	WebKit_debug.dll!KJS::JSObject::call(KJS::ExecState * exec=0x0012f390, KJS::JSObject * thisObj=0x05e00000, const KJS::List & args={...})  Line 96 + 0x1b bytes	C++
 	WebKit_debug.dll!KJS::FunctionProtoFunc::callAsFunction(KJS::ExecState * exec=0x0012f390, KJS::JSObject * thisObj=0x05e096a0, const KJS::List & args={...})  Line 143 + 0x17 bytes	C++
 	WebKit_debug.dll!KJS::JSObject::call(KJS::ExecState * exec=0x0012f390, KJS::JSObject * thisObj=0x05e096a0, const KJS::List & args={...})  Line 96 + 0x1b bytes	C++
 	WebKit_debug.dll!KJS::FunctionCallDotNode::inlineEvaluate(KJS::ExecState * exec=0x0012f390)  Line 1223 + 0x14 bytes	C++
 	WebKit_debug.dll!KJS::FunctionCallDotNode::evaluate(KJS::ExecState * exec=0x0012f390)  Line 1229	C++
 	WebKit_debug.dll!KJS::ExprStatementNode::execute(KJS::ExecState * exec=0x0012f390)  Line 3640 + 0x21 bytes	C++
 	WebKit_debug.dll!KJS::statementListExecute(WTF::Vector<WTF::RefPtr<KJS::StatementNode>,0> & statements={...}, KJS::ExecState * exec=0x0012f390)  Line 3593 + 0x29 bytes	C++
 	WebKit_debug.dll!KJS::BlockNode::execute(KJS::ExecState * exec=0x0012f390)  Line 3618 + 0x10 bytes	C++
 	WebKit_debug.dll!KJS::FunctionBodyNode::execute(KJS::ExecState * exec=0x0012f390)  Line 4520	C++
 	WebKit_debug.dll!KJS::FunctionImp::callAsFunction(KJS::ExecState * exec=0x0387e4f8, KJS::JSObject * thisObj=0x05e00000, const KJS::List & args={...})  Line 76 + 0x21 bytes	C++
 	WebKit_debug.dll!KJS::JSObject::call(KJS::ExecState * exec=0x0387e4f8, KJS::JSObject * thisObj=0x05e00000, const KJS::List & args={...})  Line 96 + 0x1b bytes	C++
 	WebKit_debug.dll!WebCore::JSAbstractEventListener::handleEvent(WebCore::Event * ele=0x06b646f0, bool isWindowEvent=true)  Line 114 + 0x14 bytes	C++
 	WebKit_debug.dll!WebCore::Document::handleWindowEvent(WebCore::Event * evt=0x06b646f0, bool useCapture=false)  Line 2458 + 0x2e bytes	C++
 	WebKit_debug.dll!WebCore::EventTargetNode::dispatchWindowEvent(const WebCore::AtomicString & eventType={...}, bool canBubbleArg=false, bool cancelableArg=false)  Line 148	C++
 	WebKit_debug.dll!WebCore::Document::implicitClose()  Line 1455	C++
 	WebKit_debug.dll!WebCore::FrameLoader::checkCallImplicitClose()  Line 1307	C++
 	WebKit_debug.dll!WebCore::FrameLoader::checkCompleted()  Line 1263	C++
 	WebKit_debug.dll!WebCore::FrameLoader::completed()  Line 1887	C++
 	WebKit_debug.dll!WebCore::FrameLoader::checkCompleted()  Line 1267	C++
 	WebKit_debug.dll!WebCore::FrameLoader::loadDone()  Line 1227	C++
 	WebKit_debug.dll!WebCore::DocLoader::setLoadInProgress(bool load=false)  Line 205	C++
 	WebKit_debug.dll!WebCore::Loader::didFinishLoading(WebCore::SubresourceLoader * loader=0x06b24440)  Line 118	C++
 	WebKit_debug.dll!WebCore::SubresourceLoader::didFinishLoading()  Line 193 + 0x21 bytes	C++
 	WebKit_debug.dll!WebCore::ResourceLoader::didFinishLoading(WebCore::ResourceHandle * __formal=0x03c553a8)  Line 362 + 0xf bytes	C++
 	WebKit_debug.dll!WebCore::didFinishLoading(_CFURLConnection * conn=0x03d2b788, const void * clientInfo=0x03c553a8)  Line 111 + 0x1e bytes	C++
 	CFNetwork_debug.dll!sendDidFinishLoadingCallback(_CFURLConnection * conn=0x03d2b788, CFURLConnectionQueueElement * event=0x06a5b080)  Line 1368 + 0x1b bytes	C
 	CFNetwork_debug.dll!_CFURLConnectionSendCallbacks(void * theConn=0x03d2b788)  Line 754 + 0xd bytes	C
 	CFNetwork_debug.dll!_CFURLConnectionWndProc(HWND__ * hWnd=0x00060a0e, unsigned int message=1231, unsigned int wParam=64141192, long lParam=0)  Line 520 + 0x9 bytes	C

[Adam Roben (:aroben)]

<rdar://problem/5686670>

[Adam Roben (:aroben)]

Fixed in r29474

[Adam Roben (:aroben)]

This seems to not quite be fixed. I'm still seeing the same crash after r29474.

[Maciej Stachowiak]

I could not reproduce this with a version of WebKit that GCs on every allocation and neither could Cameron.

[Adam Roben (:aroben)]

I can still reproduce this about 1 in 10 times on a debug Windows build of r29485.

[Cameron Zwarich (cpst)]

Adam, can you try the patch in attachment 18458 [details]?

[Cameron Zwarich (cpst)]

Adam tried out my latest patch (attachment 18461 [details]) for bug 16868, and he said that it fixes the crash for him. Commenting out the lines

        if (exec->m_savedExec != exec->m_callingExec && exec->m_savedExec)
            exec->m_savedExec->mark();

makes it crash, and commenting out the lines

        if (exec->m_activation && exec->m_activation->isOnStack())
            exec->m_activation->markChildren();

doesn't seem make it crash after quite a number of reloads. Is that added bit actually necessary now that we are checking savedExec? The patch adding the m_activation marking made the crash occur less frequently, so it must be possible for m_activation to not be in the scope chain of an ExecState in the callingExec chain, but will any such ActivationImp also be in the scope chain of an ExecState in the savedExec chain?

We should really find an explicit example or code path where the m_activation marking is necessary.

[Gavin Barraclough]

I do not believe that this still crashes. :-)