138497 2014-11-07 00:17:24 -0800 ASSERTION failed in get-by-pname.js when run with JSC_useLLINT=false and 2 other configurations 2016-06-06 23:31:09 -0700 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 1 mark.lam mark.lam commit-queue joepeck simon.fraser webkit-bug-importer oldest_to_newest 1047033 0 mark.lam 2014-11-07 00:17:24 -0800 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 1047035 1 mark.lam 2014-11-07 00:26:29 -0800 The test has been skipped in r175744: <http://trac.webkit.org/r175744>. Will unskip when the fix is available. 1047109 2 webkit-bug-importer 2014-11-07 10:31:52 -0800 <rdar://problem/18909792> 1047113 3 mark.lam 2014-11-07 10:44:49 -0800 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. 1047114 4 mark.lam 2014-11-07 10:48:54 -0800 Just confirmed that the failures were only on debug builds where assertions are enabled. 1047119 5 mark.lam 2014-11-07 11:02:09 -0800 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**) 1199900 6 joepeck 2016-06-06 21:56:13 -0700 Mark, this test appears to pass for me in Release and Debug. Should we try unskipping the test? 1199904 7 mark.lam 2016-06-06 22:21:55 -0700 (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. 1199914 8 280674 joepeck 2016-06-06 22:41:43 -0700 Created attachment 280674 [PATCH] Proposed Fix 1199915 9 280674 mark.lam 2016-06-06 22:42:21 -0700 Comment on attachment 280674 [PATCH] Proposed Fix r=me 1199947 10 280674 commit-queue 2016-06-06 23:31:05 -0700 Comment on attachment 280674 [PATCH] Proposed Fix Clearing flags on attachment: 280674 Committed r201744: <http://trac.webkit.org/changeset/201744> 1199948 11 commit-queue 2016-06-06 23:31:09 -0700 All reviewed patches have been landed. Closing bug. 280674 2016-06-06 22:41:43 -0700 2016-06-06 23:31:05 -0700 [PATCH] Proposed Fix unskip-3.patch text/plain 1051 joepeck ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5nZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxv ZwppbmRleCBlMTk5ZTVhLi43MTkyYTljIDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9DaGFuZ2VM b2cKKysrIGIvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCkBAIC0xLDUgKzEsMTYgQEAKIDIwMTYtMDYt MDYgIEpvc2VwaCBQZWNvcmFybyAgPHBlY29yYXJvQGFwcGxlLmNvbT4KIAorICAgICAgICBBU1NF UlRJT04gZmFpbGVkIGluIGdldC1ieS1wbmFtZS5qcyB3aGVuIHJ1biB3aXRoIEpTQ191c2VMTElO VD1mYWxzZSBhbmQgMiBvdGhlciBjb25maWd1cmF0aW9ucworICAgICAgICBodHRwczovL2J1Z3Mu d2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTM4NDk3CisgICAgICAgIDxyZGFyOi8vcHJvYmxl bS8xODkwOTc5Mj4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAg ICAgICAqIGpzL3NjcmlwdC10ZXN0cy9nZXQtYnktcG5hbWUuanM6CisgICAgICAgIFRlc3QgaXMg bm8gbG9uZ2VyIGZhaWxpbmcuIExldHMgdW5za2lwLgorCisyMDE2LTA2LTA2ICBKb3NlcGggUGVj b3Jhcm8gIDxwZWNvcmFyb0BhcHBsZS5jb20+CisKICAgICAgICAgVW5za2lwIGpzL3NjcmlwdC10 ZXN0cy9jbGFzcy1zeW50YXgtc2NvcGluZy5qcwogICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0 Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTU4NDU4CiAKZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2pz L3NjcmlwdC10ZXN0cy9nZXQtYnktcG5hbWUuanMgYi9MYXlvdXRUZXN0cy9qcy9zY3JpcHQtdGVz dHMvZ2V0LWJ5LXBuYW1lLmpzCmluZGV4IDBiMTgxZjAuLmFmYTA3M2YgMTAwNjQ0Ci0tLSBhL0xh eW91dFRlc3RzL2pzL3NjcmlwdC10ZXN0cy9nZXQtYnktcG5hbWUuanMKKysrIGIvTGF5b3V0VGVz dHMvanMvc2NyaXB0LXRlc3RzL2dldC1ieS1wbmFtZS5qcwpAQCAtMSw1ICsxLDMgQEAKLS8vQCBz a2lwCi0KIGRlc2NyaXB0aW9uKAogIlRoaXMgdGVzdHMgdGhhdCBvcF9nZXRfYnlfcG5hbWUgaXMg Y29tcGlsZWQgY29ycmVjdGx5LiIKICk7Cg==