Bug 84073 - Exception stack traces aren't complete when the exception starts in native code
Summary: Exception stack traces aren't complete when the exception starts in native code
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Oliver Hunt
URL:
Keywords: InRadar, LayoutTestFailure
Depends on: 84097
Blocks: 79668
  Show dependency treegraph
 
Reported: 2012-04-16 13:58 PDT by Oliver Hunt
Modified: 2012-06-08 04:09 PDT (History)
13 users (show)

See Also:


Attachments
Patch (36.95 KB, patch)
2012-04-16 14:02 PDT, Oliver Hunt
no flags Details | Formatted Diff | Diff
Patch (36.99 KB, patch)
2012-04-16 14:33 PDT, Oliver Hunt
no flags Details | Formatted Diff | Diff
Patch (37.96 KB, patch)
2012-04-16 14:59 PDT, Oliver Hunt
no flags Details | Formatted Diff | Diff
Patch (48.58 KB, patch)
2012-04-19 15:03 PDT, Oliver Hunt
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Hunt 2012-04-16 13:58:14 PDT
Exception stack traces aren't complete when the exception starts in native code
Comment 1 Oliver Hunt 2012-04-16 14:02:27 PDT
Created attachment 137398 [details]
Patch
Comment 2 Build Bot 2012-04-16 14:25:33 PDT
Comment on attachment 137398 [details]
Patch

Attachment 137398 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/12410831
Comment 3 Oliver Hunt 2012-04-16 14:33:54 PDT
Created attachment 137405 [details]
Patch
Comment 4 Build Bot 2012-04-16 14:46:05 PDT
Comment on attachment 137405 [details]
Patch

Attachment 137405 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/12417236
Comment 5 Gavin Barraclough 2012-04-16 14:52:23 PDT
Comment on attachment 137405 [details]
Patch

r+ assuming it builds ;-)
Comment 6 Oliver Hunt 2012-04-16 14:59:48 PDT
Created attachment 137407 [details]
Patch
Comment 7 Build Bot 2012-04-16 15:23:55 PDT
Comment on attachment 137407 [details]
Patch

Attachment 137407 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/12412588
Comment 8 Oliver Hunt 2012-04-16 15:27:25 PDT
Committed r114309: <http://trac.webkit.org/changeset/114309>
Comment 9 Alexey Proskuryakov 2012-04-16 21:43:25 PDT
This was rolled out in <http://trac.webkit.org/changeset/114317>, reopening.
Comment 10 Oliver Hunt 2012-04-19 15:03:38 PDT
Created attachment 137987 [details]
Patch
Comment 11 Oliver Hunt 2012-04-19 17:38:22 PDT
Committed r114702: <http://trac.webkit.org/changeset/114702>
Comment 12 Csaba Osztrogonác 2012-04-20 00:59:10 PDT
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?
Comment 13 Oliver Hunt 2012-04-20 09:06:40 PDT
(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?
Comment 14 Csaba Osztrogonác 2012-04-20 09:27:57 PDT
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.
Comment 15 Philippe Normand 2012-04-23 08:02:09 PDT
(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.
Comment 16 Oliver Hunt 2012-04-23 08:51:58 PDT
(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
Comment 17 Philippe Normand 2012-04-23 09:08:40 PDT
(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.
Comment 18 Csaba Osztrogonác 2012-04-24 01:12:15 PDT
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*)
Comment 19 Philippe Normand 2012-04-24 01:33:38 PDT
(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.
Comment 20 Csaba Osztrogonác 2012-04-24 01:37:35 PDT
I skipped them on Qt - http://trac.webkit.org/changeset/115010/trunk/LayoutTests/platform/qt/Skipped

Please unskip them with the proper fix.
Comment 21 Jessie Berlin 2012-06-01 09:49:33 PDT
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
Comment 22 Radar WebKit Bug Importer 2012-06-01 09:50:59 PDT
<rdar://problem/11575416>
Comment 23 Jessie Berlin 2012-06-01 09:58:40 PDT
Skipped the tests on Windows in http://trac.webkit.org/changeset/119246
Comment 24 Zan Dobersek 2012-06-06 06:43:14 PDT
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.
Comment 25 Zan Dobersek 2012-06-08 04:09:15 PDT
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/