The get_by_pname test changes in r175724 exposed some latent bugs that is bleeding the bots: https://build.webkit.org/builders/Apple%20Yosemite%2032-bit%20JSC%20%28BuildAndTest%29?numbuilds=100 I confirmed that the issue has nothing to do with the fix in that change. Here's a reduced test case that will illustrate the issue: === BEGIN test.js === function foo(o, v) { var result = 0; for (var n in o) result += v[n] ? v[n] : 0; return result; } var o = {a:1, b:3, c:7}; var a = [1, 2, 3]; var o1 = {"1":1, "2":3, "3":7}; for (var i = 0; i <= 1; i++) { foo(a, 'abc'); foo(a, o); foo(a, o1); } === END test.js === Run the test using jsc as follows: $ JSC_useLLInt=0 DYLD_FRAMEWORK_PATH=/path/to/your/OpenSource/WebKitBuild/Debug/ WebKitBuild/Debug/jsc test.js
The test has been skipped in r175744: <http://trac.webkit.org/r175744>. Will unskip when the fix is available.
<rdar://problem/18909792>
If I disable the failed assertion, the useLLInt=false run does not crash. Similarly, the another failing configuration: ... jsc --enableFunctionDotArguments=true --testTheFTL=true --useFTLJIT=true --enableExperimentalFTLCoverage=true --enableConcurrentJIT=false --thresholdForJITAfterWarmUp=100 --thresholdForJITAfterWarmUp=10 --thresholdForJITSoon=10 --thresholdForOptimizeAfterWarmUp=20 --thresholdForOptimizeAfterLongWarmUp=20 --thresholdForOptimizeSoon=20 --thresholdForFTLOptimizeAfterWarmUp=20 --thresholdForFTLOptimizeSoon=20 LayoutTests/resources/standalone-pre.js LayoutTests/js/script-tests/get-by-pname.js ... doe not crash with the failed assertion disabled. Ditto with the 3rd configuration: ... jsc --useFTLJIT=false --enableFunctionDotArguments=true --enableConcurrentJIT=false --thresholdForJITAfterWarmUp=100 --thresholdForJITAfterWarmUp=10 --thresholdForJITSoon=10 --thresholdForOptimizeAfterWarmUp=20 --thresholdForOptimizeAfterLongWarmUp=20 --thresholdForOptimizeSoon=20 --thresholdForFTLOptimizeAfterWarmUp=20 --thresholdForFTLOptimizeSoon=20 LayoutTests/resources/standalone-pre.js LayoutTests/js/script-tests/get-by-pname.js This could very well just be a case of a bad assertion.
Just confirmed that the failures were only on debug builds where assertions are enabled.
The eager FTL configuration did have a different more serious looking assertion failure once I disable the one in operationGetByValDefault(). This other assertion is: DFG ASSERTION FAILED: Edge verification error: @109->Check:Cell:@9 was expected to have type Cell but has type Int32 (2097152) /Volumes/Data/ws5/OpenSource/Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h(112) : void JSC::DFG::AbstractInterpreter<JSC::DFG::InPlaceAbstractState>::verifyEdge(JSC::DFG::Node *, JSC::DFG::Edge) [AbstractStateType = JSC::DFG::InPlaceAbstractState] 1 0x10099de90 WTFCrashWithSecurityImplication 2 0x1003016e3 JSC::DFG::crash(JSC::DFG::Graph&, WTF::CString const&, char const*, int, char const*, char const*) 3 0x10030175b JSC::DFG::Graph::handleAssertionFailure(JSC::DFG::Node*, char const*, int, char const*, char const*) 4 0x100249734 JSC::DFG::AbstractInterpreter<JSC::DFG::InPlaceAbstractState>::verifyEdge(JSC::DFG::Node*, JSC::DFG::Edge) 5 0x100244406 JSC::DFG::AbstractInterpreter<JSC::DFG::InPlaceAbstractState>::verifyEdges(JSC::DFG::Node*) 6 0x100239ad5 JSC::DFG::AbstractInterpreter<JSC::DFG::InPlaceAbstractState>::executeEffects(unsigned int, JSC::DFG::Node*) 7 0x1003b7643 JSC::DFG::AbstractInterpreter<JSC::DFG::InPlaceAbstractState>::executeEffects(unsigned int) 8 0x10049e767 JSC::FTL::LowerDFGToLLVM::compileNode(unsigned int) 9 0x10049db81 JSC::FTL::LowerDFGToLLVM::compileBlock(JSC::DFG::BasicBlock*) 10 0x10049bcc8 JSC::FTL::LowerDFGToLLVM::lower() 11 0x10049926e JSC::FTL::lowerDFGToLLVM(JSC::FTL::State&) 12 0x10038c71b JSC::DFG::Plan::compileInThreadImpl(JSC::DFG::LongLivedState&) 13 0x10038b826 JSC::DFG::Plan::compileInThread(JSC::DFG::LongLivedState&, JSC::DFG::ThreadData*) 14 0x1002e3333 JSC::DFG::compileImpl(JSC::VM&, JSC::CodeBlock*, JSC::CodeBlock*, JSC::DFG::CompilationMode, unsigned int, JSC::Operands<JSC::JSValue, JSC::OperandValueTraits<JSC::JSValue> > const&, WTF::PassRefPtr<JSC::DeferredCompilationCallback>) 15 0x1002e2ce4 JSC::DFG::compile(JSC::VM&, JSC::CodeBlock*, JSC::CodeBlock*, JSC::DFG::CompilationMode, unsigned int, JSC::Operands<JSC::JSValue, JSC::OperandValueTraits<JSC::JSValue> > const&, WTF::PassRefPtr<JSC::DeferredCompilationCallback>) 16 0x10035291a JSC::DFG::triggerFTLReplacementCompile(JSC::VM*, JSC::CodeBlock*, JSC::DFG::JITCode*) 17 0x1003526bc triggerTierUpNow 18 0x5864f8e362cd 19 0x5864f8e2f6f1 20 0x100767869 vmEntryToJavaScript 21 0x1005f521a JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) 22 0x1005d6806 JSC::Interpreter::execute(JSC::EvalExecutable*, JSC::ExecState*, JSC::JSValue, JSC::JSScope*) 23 0x1005d5e64 JSC::eval(JSC::ExecState*) 24 0x100605f7d operationCallEval 25 0x5864f8e15ee5 26 0x100767869 vmEntryToJavaScript 27 0x1005f521a JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*) 28 0x1005d9a54 JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::JSObject*) 29 0x100176cd0 JSC::evaluate(JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, JSC::JSValue*) 30 0x100001d54 runWithScripts(GlobalObject*, WTF::Vector<Script, 0ul, WTF::CrashOnOverflow> const&, bool) 31 0x1000013cb jscmain(int, char**)
Mark, this test appears to pass for me in Release and Debug. Should we try unskipping the test?
(In reply to comment #6) > Mark, this test appears to pass for me in Release and Debug. Should we try > unskipping the test? Let's unskip the test. The FTL also uses B3 now. So things have changed a lot. Let's give it a try.
Created attachment 280674 [details] [PATCH] Proposed Fix
Comment on attachment 280674 [details] [PATCH] Proposed Fix r=me
Comment on attachment 280674 [details] [PATCH] Proposed Fix Clearing flags on attachment: 280674 Committed r201744: <http://trac.webkit.org/changeset/201744>
All reviewed patches have been landed. Closing bug.