Bug 84073 – Exception stack traces aren't complete when the exception starts in native code

• Status: REOPENED
• Component: JavaScriptCore

[Oliver Hunt]

Exception stack traces aren't complete when the exception starts in native code

[Oliver Hunt]

Created attachment 137398 [details]
Patch

[Build Bot]

Comment on attachment 137398 [details]
Patch

Attachment 137398 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/12410831

[Oliver Hunt]

Created attachment 137405 [details]
Patch

[Build Bot]

Comment on attachment 137405 [details]
Patch

Attachment 137405 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/12417236

[Gavin Barraclough]

Comment on attachment 137405 [details]
Patch

r+ assuming it builds ;-)

[Oliver Hunt]

Created attachment 137407 [details]
Patch

[Build Bot]

Comment on attachment 137407 [details]
Patch

Attachment 137407 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/12412588

[Oliver Hunt]

Committed r114309: <http://trac.webkit.org/changeset/114309>

[Alexey Proskuryakov]

This was rolled out in <http://trac.webkit.org/changeset/114317>, reopening.

[Oliver Hunt]

Created attachment 137987 [details]
Patch

[Oliver Hunt]

Committed r114702: <http://trac.webkit.org/changeset/114702>

[Csaba Osztrogonác]

Reopen, because it made tests assert in debug mode on x86_64 GTK and Qt bots:
- http://build.webkit.sed.hu/results/x86-64%20Linux%20Qt%20Debug/r114707
%20%2822364%29/results.html
- http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug/r114705%20%2832610%29/results.html

Could you check and fix this regression?

[Oliver Hunt]

(In reply to comment #12)
> Reopen, because it made tests assert in debug mode on x86_64 GTK and Qt bots:
> - http://build.webkit.sed.hu/results/x86-64%20Linux%20Qt%20Debug/r114707
> %20%2822364%29/results.html
> - http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug/r114705%20%2832610%29/results.html
> 
> Could you check and fix this regression?

What are the exact configuration settings of the DFG hit, baseline hit, and LLint on qt/gtk64?

[Csaba Osztrogonác]

I don't know anything about DFG, so I can't help you ... I'm only a working bee who noticed that the bots are red because of this patch.

[Philippe Normand]

(In reply to comment #13)
> (In reply to comment #12)
> > Reopen, because it made tests assert in debug mode on x86_64 GTK and Qt bots:
> > - http://build.webkit.sed.hu/results/x86-64%20Linux%20Qt%20Debug/r114707
> > %20%2822364%29/results.html
> > - http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug/r114705%20%2832610%29/results.html
> > 
> > Could you check and fix this regression?
> 
> What are the exact configuration settings of the DFG hit, baseline hit, and LLint on qt/gtk64?

I'm not familiar with JSC internals, where can those informations be retrieved? I'd be happy to help.

[Oliver Hunt]

(In reply to comment #15)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > Reopen, because it made tests assert in debug mode on x86_64 GTK and Qt bots:
> > > - http://build.webkit.sed.hu/results/x86-64%20Linux%20Qt%20Debug/r114707
> > > %20%2822364%29/results.html
> > > - http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug/r114705%20%2832610%29/results.html
> > > 
> > > Could you check and fix this regression?
> > 
> > What are the exact configuration settings of the DFG hit, baseline hit, and LLint on qt/gtk64?
> 
> I'm not familiar with JSC internals, where can those informations be retrieved? I'd be happy to help.

Look at what gtk/qt sets up in passes in as cflags, and platform.h


ENABLE_DFG, ENABLE_JIT, and ENABLE_LLINT are the ones to look for

[Philippe Normand]

(In reply to comment #16)
> 
> Look at what gtk/qt sets up in passes in as cflags, and platform.h
> 
> 
> ENABLE_DFG, ENABLE_JIT, and ENABLE_LLINT are the ones to look for

I can't find ENABLE_DFG but there's a ENABLE_DFG_JIT set to 1.
ENABLE_JIT is set to 1 and ENABLE_LLINT is set to 0. This is for GTK 64-bit.

[Csaba Osztrogonác]

After http://trac.webkit.org/changeset/114953 bots work again, but there are two failing tests (assertion) because of this bug:

http://build.webkit.sed.hu/results/x86-64%20Linux%20Qt%20Debug/r114999%20%2822448%29/results.html

crash log for DumpRenderTree (pid 2286):
STDOUT: <empty>
STDERR: ASSERTION FAILED: callFrame == globalData->topCallFrame || callFrame == callFrame->lexicalGlobalObject()->globalExec() || callFrame == callFrame->dynamicGlobalObject()->globalExec()
STDERR: ../../../../Source/JavaScriptCore/interpreter/Interpreter.cpp(983) : static void JSC::Interpreter::addStackTraceIfNecessary(JSC::CallFrame*, JSC::JSObject*)

[Philippe Normand]

(In reply to comment #18)
> After http://trac.webkit.org/changeset/114953 bots work again, but there are two failing tests (assertion) because of this bug:
> 
> http://build.webkit.sed.hu/results/x86-64%20Linux%20Qt%20Debug/r114999%20%2822448%29/results.html
> 
> crash log for DumpRenderTree (pid 2286):
> STDOUT: <empty>
> STDERR: ASSERTION FAILED: callFrame == globalData->topCallFrame || callFrame == callFrame->lexicalGlobalObject()->globalExec() || callFrame == callFrame->dynamicGlobalObject()->globalExec()
> STDERR: ../../../../Source/JavaScriptCore/interpreter/Interpreter.cpp(983) : static void JSC::Interpreter::addStackTraceIfNecessary(JSC::CallFrame*, JSC::JSObject*)

Right, I see it in GTK too:
http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug/r115001%20(32712)/results.html

The tests crashing are plugins/npruntime/object-from-destroyed-plugin.html and plugins/npruntime/object-from-destroyed-plugin-in-subframe.html

You can see the crash logs in the page linked above.

[Csaba Osztrogonác]

I skipped them on Qt - http://trac.webkit.org/changeset/115010/trunk/LayoutTests/platform/qt/Skipped

Please unskip them with the proper fix.

[Jessie Berlin]

This is also happening on Windows when running plugins/npruntime/object-from-destroyed-plugin-in-subframe.html and plugins/npruntime/object-from-destroyed-plugin.html 

I am going to skip those tests on Windows.

void Interpreter::addStackTraceIfNecessary(CallFrame* callFrame, JSObject* error)
{
    JSGlobalData* globalData = &callFrame->globalData();
    ASSERT(callFrame == globalData->topCallFrame || callFrame == callFrame->lexicalGlobalObject()->globalExec() || callFrame == callFrame->dynamicGlobalObject()->globalExec());

Unhandled exception at 0x67fd437e (JavaScriptCore.dll) in DumpRenderTree.exe: 0xC0000005: Access violation writing location 0xbbadbeef.

JavaScriptCore.dll!JSC::Interpreter::addStackTraceIfNecessary(JSC::ExecState * callFrame=0x05a70188, JSC::JSObject * error=0x02b01e90)  Line 983 + 0x5c bytes	C++
 	JavaScriptCore.dll!JSC::throwError(JSC::ExecState * exec=0x05a70188, JSC::JSObject * error=0x02b01e90)  Line 165 + 0xd bytes	C++
 	WebKit.dll!JSC::Bindings::RuntimeObject::throwInvalidAccessError(JSC::ExecState * exec=0x05a70188)  Line 327 + 0x27 bytes	C++
 	WebKit.dll!JSC::Bindings::RuntimeObject::defaultValue(const JSC::JSObject * object=0x02b021d0, JSC::ExecState * exec=0x05a70188, JSC::PreferredPrimitiveType hint=PreferString)  Line 248 + 0x9 bytes	C++
 	JavaScriptCore.dll!JSC::JSObject::toPrimitive(JSC::ExecState * exec=0x05a70188, JSC::PreferredPrimitiveType preferredType=PreferString)  Line 799 + 0x1f bytes	C++
 	JavaScriptCore.dll!JSC::JSCell::toPrimitive(JSC::ExecState * exec=0x05a70188, JSC::PreferredPrimitiveType preferredType=PreferString)  Line 140 + 0x14 bytes	C++
 	JavaScriptCore.dll!JSC::JSValue::toStringSlowCase(JSC::ExecState * exec=0x05a70188)  Line 280	C++
 	JavaScriptCore.dll!JSC::JSValue::toString(JSC::ExecState * exec=0x05a70188)  Line 501	C++
 	JavaScriptCore.dll!JSC::createNotAFunctionError(JSC::ExecState * exec=0x05a70188, JSC::JSValue value={...})  Line 134 + 0x15 bytes	C++
 	JavaScriptCore.dll!cti_op_call_NotJSFunction(void * * args=0x0019d61c)  Line 2302 + 0x16 bytes	C++
 	JavaScriptCore.dll!@cti_op_create_this@4()  + 0x16f bytes	C++
 	JavaScriptCore.dll!JSC::JITCode::execute(JSC::RegisterFile * registerFile=0x054091ec, JSC::ExecState * callFrame=0x05a70188, JSC::JSGlobalData * globalData=0x020f4d98)  Line 127 + 0x2d bytes	C++
 	JavaScriptCore.dll!JSC::Interpreter::execute(JSC::EvalExecutable * eval=0x05769970, JSC::ExecState * callFrame=0x05a70150, JSC::JSValue thisValue={...}, JSC::ScopeChainNode * scopeChain=0x034970f0, int globalRegisterOffset=49)  Line 1614 + 0x2b bytes	C++
 	JavaScriptCore.dll!JSC::eval(JSC::ExecState * callFrame=0x05a70150)  Line 462 + 0x4e bytes	C++
 	JavaScriptCore.dll!cti_op_call_eval(void * * args=0x0019e16c)  Line 3108 + 0xd bytes	C++
 	JavaScriptCore.dll!@cti_op_create_this@4()  + 0x16f bytes	C++
 	JavaScriptCore.dll!JSC::JITCode::execute(JSC::RegisterFile * registerFile=0x054091ec, JSC::ExecState * callFrame=0x05a70040, JSC::JSGlobalData * globalData=0x020f4d98)  Line 127 + 0x2d bytes	C++
 	JavaScriptCore.dll!JSC::Interpreter::executeCall(JSC::ExecState * callFrame=0x0322e4c8, JSC::JSObject * function=0x02b02d50, JSC::CallType callType=CallTypeJS, const JSC::CallData & callData={...}, JSC::JSValue thisValue={...}, const JSC::ArgList & args={...})  Line 1305 + 0x2a bytes	C++
 	JavaScriptCore.dll!JSC::call(JSC::ExecState * exec=0x0322e4c8, JSC::JSValue functionObject={...}, JSC::CallType callType=CallTypeJS, const JSC::CallData & callData={...}, JSC::JSValue thisValue={...}, const JSC::ArgList & args={...})  Line 39 + 0x3c bytes	C++
 	WebKit.dll!WebCore::JSMainThreadExecState::call(JSC::ExecState * exec=0x0322e4c8, JSC::JSValue functionObject={...}, JSC::CallType callType=CallTypeJS, const JSC::CallData & callData={...}, JSC::JSValue thisValue={...}, const JSC::ArgList & args={...})  Line 56 + 0x29 bytes	C++
 	WebKit.dll!WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext * scriptExecutionContext=0x060807e4, WebCore::Event * event=0x06099380)  Line 133 + 0x64 bytes	C++
 	WebKit.dll!WebCore::EventTarget::fireEventListeners(WebCore::Event * event=0x06099380, WebCore::EventTargetData * d=0x0606e690, WTF::Vector<WebCore::RegisteredEventListener,1> & entry=[1]({listener=0x060b1300 {m_functionName={...} m_eventParameterName={...} m_code={...} ...} useCapture=false }))  Line 231 + 0x22 bytes	C++
 	WebKit.dll!WebCore::EventTarget::fireEventListeners(WebCore::Event * event=0x06099380)  Line 200	C++
 	WebKit.dll!WebCore::DOMWindow::dispatchEvent(WTF::PassRefPtr<WebCore::Event> prpEvent={...}, WTF::PassRefPtr<WebCore::EventTarget> prpTarget={...})  Line 1669 + 0x11 bytes	C++
 	WebKit.dll!WebCore::DOMWindow::dispatchLoadEvent()  Line 1644	C++
 	WebKit.dll!WebCore::Document::dispatchWindowLoadEvent()  Line 3983	C++
 	WebKit.dll!WebCore::Document::implicitClose()  Line 2446	C++
 	WebKit.dll!WebCore::FrameLoader::checkCallImplicitClose()  Line 762	C++
 	WebKit.dll!WebCore::FrameLoader::checkCompleted()  Line 709	C++
 	WebKit.dll!WebCore::FrameLoader::finishedParsing()  Line 642	C++
 	WebKit.dll!WebCore::Document::finishedParsing()  Line 4733	C++
 	WebKit.dll!WebCore::HTMLTreeBuilder::finished()  Line 2807 + 0x18 bytes	C++
 	WebKit.dll!WebCore::HTMLDocumentParser::end()  Line 382	C++
 	WebKit.dll!WebCore::HTMLDocumentParser::attemptToRunDeferredScriptsAndEnd()  Line 391	C++
 	WebKit.dll!WebCore::HTMLDocumentParser::prepareToStopParsing()  Line 154	C++
 	WebKit.dll!WebCore::HTMLDocumentParser::attemptToEnd()  Line 402 + 0xf bytes	C++
 	WebKit.dll!WebCore::HTMLDocumentParser::finish()  Line 430	C++
 	WebKit.dll!WebCore::DocumentWriter::end()  Line 241 + 0x1d bytes	C++
 	WebKit.dll!WebCore::DocumentLoader::finishedLoading()  Line 300	C++
 	WebKit.dll!WebCore::MainResourceLoader::didFinishLoading(double finishTime=0.00000000000000000)  Line 545	C++
 	WebKit.dll!WebCore::ResourceLoader::didFinishLoading(WebCore::ResourceHandle * __formal=0x06084248, double finishTime=0.00000000000000000)  Line 435 + 0x18 bytes	C++
 	WebKit.dll!WebCore::didFinishLoading(_CFURLConnection * conn=0x060843d8, const void * clientInfo=0x06084248)  Line 301 + 0x26 bytes	C++
 	CFNetwork.dll!URLConnectionClient::_clientDidFinishLoading(URLConnectionClient::ClientConnectionEventQueue * preQ=0x0019e950)  Line 1739 + 0x2b bytes	C++
 	CFNetwork.dll!URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload(XConnectionEventInfo<enum XClientEvent,XClientEventParams> * e=0x054e64c4, long count=3)  Line 2256	C++
 	CFNetwork.dll!URLConnectionClient::processEvents()  Line 360 + 0x21 bytes	C++
 	CFNetwork.dll!URLConnectionWndProc(HWND__ * hWnd=0x001802d2, unsigned int message=1231, unsigned int wParam=101204952, long lParam=0)  Line 109	C++
 	user32.dll!_InternalCallWinProc@20()  + 0x23 bytes	
 	user32.dll!_UserCallWinProcCheckWow@32()  + 0xd3 bytes	
 	user32.dll!_DispatchMessageWorker@8()  + 0xee bytes	
 	user32.dll!_DispatchMessageW@4()  + 0xf bytes	
 	DumpRenderTree.dll!runTest(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & testPathOrURL="H:\home\jhoneycutt\src\OpenSource\LayoutTests\plugins\npruntime\object-from-destroyed-plugin-in-subframe.html")  Line 1049 + 0xf bytes	C++
 	DumpRenderTree.dll!dllLauncherEntryPoint(int argc=2, const char * * argv=0x00aa6f58)  Line 1431 + 0x28 bytes	C++
 	DumpRenderTree.exe!main(int argc=2, const char * * argv=0x00aa6f58)  Line 198 + 0x10 bytes	C++
 	DumpRenderTree.exe!__tmainCRTStartup()  Line 597 + 0x17 bytes	C
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0xe bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x23 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes

[Radar WebKit Bug Importer]

<rdar://problem/11575416>

[Jessie Berlin]

Skipped the tests on Windows in http://trac.webkit.org/changeset/119246

[Zan Dobersek]

The crashes are fixed with the following changes in JITStubs.cpp:

diff --git a/Source/JavaScriptCore/jit/JITStubs.cpp b/Source/JavaScriptCore/jit/JITStubs.cpp
index 4aad7c9..c2a3f5e 100644
--- a/Source/JavaScriptCore/jit/JITStubs.cpp
+++ b/Source/JavaScriptCore/jit/JITStubs.cpp
@@ -2295,7 +2295,7 @@ DEFINE_STUB_FUNCTION(EncodedJSValue, op_call_NotJSFunction)
     ASSERT(callType != CallTypeJS);
     if (callType != CallTypeHost) {
         ASSERT(callType == CallTypeNone);
-        return throwExceptionFromOpCall<EncodedJSValue>(stackFrame, callFrame, STUB_RETURN_ADDRESS, createNotAFunctionError(callFrame->callerFrame(), callee));
+        return throwExceptionFromOpCall<EncodedJSValue>(stackFrame, callFrame, STUB_RETURN_ADDRESS, createNotAFunctionError(callFrame, callee));
     }
 
     EncodedJSValue returnValue;
@@ -2401,7 +2401,7 @@ DEFINE_STUB_FUNCTION(EncodedJSValue, op_construct_NotJSConstruct)
     ASSERT(constructType != ConstructTypeJS);
     if (constructType != ConstructTypeHost) {
         ASSERT(constructType == ConstructTypeNone);
-        return throwExceptionFromOpCall<EncodedJSValue>(stackFrame, callFrame, STUB_RETURN_ADDRESS, createNotAConstructorError(callFrame->callerFrame(), callee));
+        return throwExceptionFromOpCall<EncodedJSValue>(stackFrame, callFrame, STUB_RETURN_ADDRESS, createNotAConstructorError(callFrame, callee));
     }
 
     EncodedJSValue returnValue;

Looking at other calls to error-creation functions in other places, usually it's just callFrame passed to the function as the ExecState, not the callerFrame of that callFrame. But there are other such calls in JITStubs, so I'm not sure of what exactly is the appropriate way of doing this. What's certain is that the crashes go away in the affected test cases, but the attached diff surely isn't a complete fix.

[Zan Dobersek]

In the mean time, the issue was fixed in the Gtk port by enabling LLInt[1]. The two plugins tests are not crashing anymore and their test expectations will be removed.

[1] - http://trac.webkit.org/changeset/119593/