Bug 84073

Created attachment 137398 [details] Patch

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

Created attachment 137405 [details] Patch

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

Comment on attachment 137405 [details] Patch r+ assuming it builds ;-)

Created attachment 137407 [details] Patch

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

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

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

Created attachment 137987 [details] Patch

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

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?

(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 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.

(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.

(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

(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.

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*)

(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.

I skipped them on Qt - http://trac.webkit.org/changeset/115010/trunk/LayoutTests/platform/qt/Skipped Please unskip them with the proper fix.

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

<rdar://problem/11575416>

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

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.

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/