nephele
/
haikuwebkit
1
0
Fork 0
Code Issues Releases Activity
haikuwebkit/LayoutTests/js/regress-141098-expected.txt

15 lines
485 B
Plaintext
Raw Permalink Normal View History

Google doc spreadsheet reproducibly crashes when sorting https://bugs.webkit.org/show_bug.cgi?id=141098 Reviewed by Oliver Hunt. Source/JavaScriptCore: Moved the stack check to before the callee registers are allocated in the prologue() by movving it from the functionInitialization() macro. This way we can check the stack before moving the stack pointer, avoiding a crash during a "call" instruction. Before this change, we weren't even checking the stack for program and eval execution. Made a couple of supporting changes. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_stack_check): We can't just go up one frame as we may be processing an exception to an entry frame. * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: (llint_throw_from_slow_path_trampoline): Changed method to get the vm from the code block to not use the codeBlock, since we may need to continue from an exception in a native function. LayoutTests: New test. * js/regress-141098-expected.txt: Added. * js/regress-141098.html: Added. * js/script-tests/regress-141098.js: Added. (probeAndRecurse): Canonical link: https://commits.webkit.org/159593@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@180060 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-02-13 18:57:57 +00:00
Regression test for https://webkit.org/b/141098. Make sure eval() properly handles running out of stack space. This test should run without crashing.
On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
[ES] Implement RegExp.prototype.@@replace and use it for String.prototype.replace https://bugs.webkit.org/show_bug.cgi?id=156562 Reviewed by Filip Pizlo. Source/JavaScriptCore: Added builtins for String.prototype.replace as well as RegExp.prototype[Symbol.replace]. The String.prototype.replace also has an intrinsic, StringPrototypeReplaceIntrinsic. This original intrinsic was copied to make StringPrototypeReplaceRegExpIntrinsic. The difference between the two intrinsics is that StringPrototypeReplaceIntrinsic has the same checks found in the new builtin hasObservableSideEffectsForStringReplace. We implement these primordial checks for StringPrototypeReplaceIntrinsic in two places. First, we do a trial check during ByteCode parsing time to see if the current RegExp.prototype properties have changed from the original. If they have, we don't inline the intrinsic. Later, in the fixup phase, we add nodes to the IR to emit the checks at runtime. The new intrinsic StringPrototypeReplaceRegExpIntrinsic is only available via the private @replaceUsingRegExp, which is called in the String.prototype.replace builtin. It is only called after hasObservableSideEffectsForStringReplace has been called Both of these intrinsics are needed, because the JS code containing String.replace() calls runs initially in the LLint and then the baseline JIT. Even after the function tiers up to the DFG JIT, the inlining budget may not allow StringPrototypeReplaceIntrinsic to be inlined. Having StringPrototypeReplaceRegExpIntrinsic allows for the String.prototype.replace builtin to get reasonable performance before the other intrinsic is inlined or when it can't. * builtins/RegExpPrototype.js: (match): (getSubstitution): (replace): (search): (split): * builtins/StringPrototype.js: (repeat): (hasObservableSideEffectsForStringReplace): (intrinsic.StringPrototypeReplaceIntrinsic.replace): (localeCompare): New builtins for String.prototype.replace and RegExp.prototype[Symbol.replace]. * bytecode/BytecodeIntrinsicRegistry.cpp: * bytecode/BytecodeIntrinsicRegistry.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupGetAndSetLocalsInBlock): (JSC::DFG::FixupPhase::tryAddStringReplacePrimordialChecks): (JSC::DFG::FixupPhase::checkArray): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::getRegExpPrototypeProperty): * dfg/DFGGraph.h: (JSC::DFG::Graph::getRegExpPrototypeProperty): * dfg/DFGNode.h: (JSC::DFG::Node::hasHeapPrediction): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): * runtime/CommonIdentifiers.h: * runtime/Intrinsic.h: * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::replace): (JSC::stringProtoFuncReplaceUsingRegExp): (JSC::stringProtoFuncReplaceUsingStringSearch): (JSC::operationStringProtoFuncReplaceGeneric): (JSC::stringProtoFuncReplace): Deleted. Added StringReplaceRegExp intrinsic. Added checks for RegExp profiled arguments to StringReplace that mirror what is in hasObservableSideEffectsForStringReplace(). If we aren't able to add the checks, we OSR exit. Add Graph::getPrimordialRegExpPrototypeProperty() as a helper to get the primordial values from RegExp.prototype. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): Added @regExpPrototypeSymbolReplace and @hasObservableSideEffectsForStringReplace here instead og String.prototype so that we reduce the number of objects we have to traverse. * tests/es6.yaml: Changed expectations for the various replace related tests to passing. * tests/stress/regexp-replace-proxy.js: (assert): (let.getProxyNullExec.new.Proxy): (let.getSetProxyNullExec.new.Proxy): (get resetTracking): (let.getSetProxyMatches_comma.new.Proxy): (set get getSetProxyNullExec): (let.getSetProxyReplace_phoneNumber.new.Proxy): (set get getSetProxyMatches_comma): (let.getSetProxyReplaceUnicode_digit_nonGreedy.new.Proxy): (set get resetTracking): * tests/stress/string-replace-proxy.js: (assert): (let.getSetProxyReplace.new.Proxy.replace): New tests. LayoutTests: Updated tests. Needed to update js/regress-141098.js test, because builtins are only compilied when called. This test checks behavior at or near running out of stack space. It turns out that String.replace is used by the -pre.js test harness and I was running out of stack space when compiling the String.prototype.replace builting. Therefore, I added a call to testPassed() to precompile String.replace. * js/Object-getOwnPropertyNames-expected.txt: * js/regress-141098-expected.txt: * js/script-tests/Object-getOwnPropertyNames.js: * js/script-tests/regress-141098.js: (probeAndRecurse): * fast/profiler/nested-start-and-stop-profiler-expected.txt: * js/Object-getOwnPropertyNames-expected.txt: * js/dom/string-prototype-properties-expected.txt: * js/regress-141098-expected.txt: * js/script-tests/Object-getOwnPropertyNames.js: * js/script-tests/regress-141098.js: (probeAndRecurse): * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.11_String.prototype.replace/S15.5.4.11_A1_T3-expected.txt: Canonical link: https://commits.webkit.org/175172@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@200117 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-04-27 01:28:03 +00:00
PASS Initial setup
We should use different stack limits for stack checks from JS and host code. https://bugs.webkit.org/show_bug.cgi?id=159442 <rdar://problem/26889188> Reviewed by Geoffrey Garen. Source/JavaScriptCore: We have 2 stack reservedZoneSizes: 1. Options::softReservedZoneSize() 2. Options::reservedZoneSize() Respectively, there are used to define 2 stack limits based on these reserved zone sizes: 1. VM::m_softStackLimit 2. VM::m_stackLimit Options::reservedZoneSize() is the amount of the stack space that JSC guarantees to the VM and client host code for it's use. Host code that has well known stack usage characteristics (i.e. doesn't call arbitrary code) may do stack checks against the VM::m_stackLimit limit (which is computed using Options::reservedZoneSize()). Options::softReservedZoneSize() is a more conservative amount of reserved stack space. This is used to compute the VM::m_softStackLimit limit. Any code that is difficult to have its stack usage characterized (i.e. may call arbitrary code) may need more stack space for its work. Hence, these should do stack checks against the VM::m_softStackLimit limit. JS code and host code that may call into JS code falls into the category of code that may call arbitrary code. Hence, they should do stack checks against the VM::m_softStackLimit limit. Accordingly, the VM now provides 2 recursion check functions: 1. VM::isSafeToRecurseSoft() will do a stack check against VM::m_softStackLimit. In addition, for C Loop builds, VM::isSafeToRecurseSoft() will also check the CLoopStack against VM::m_cloopStackLimit. 2. VM::isSafeToRecurse() will do a stack check against VM::m_stackLimit. Also added a promise-infinite-recursion-should-not-crash.js test. * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitNodeInTailPosition): (JSC::BytecodeGenerator::emitNodeInConditionContext): * interpreter/CLoopStack.cpp: (JSC::CLoopStack::grow): * interpreter/CLoopStack.h: (JSC::CLoopStack::size): * interpreter/CLoopStackInlines.h: (JSC::CLoopStack::ensureCapacityFor): (JSC::CLoopStack::isSafeToRecurse): (JSC::CLoopStack::topOfFrameFor): * interpreter/CachedCall.h: (JSC::CachedCall::CachedCall): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * parser/Parser.cpp: * runtime/Options.h: * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (JSC::ProxyObject::getOwnPropertySlotCommon): (JSC::ProxyObject::performPut): (JSC::performProxyCall): (JSC::performProxyConstruct): (JSC::ProxyObject::performDelete): (JSC::ProxyObject::performPreventExtensions): (JSC::ProxyObject::performIsExtensible): (JSC::ProxyObject::performDefineOwnProperty): (JSC::ProxyObject::performGetOwnPropertyNames): (JSC::ProxyObject::performSetPrototype): (JSC::ProxyObject::performGetPrototype): * runtime/RegExp.cpp: (JSC::RegExp::finishCreation): (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): * runtime/StringRecursionChecker.h: (JSC::StringRecursionChecker::performCheck): * runtime/VM.cpp: (JSC::VM::setStackPointerAtVMEntry): (JSC::VM::updateSoftReservedZoneSize): (JSC::preCommitStackMemory): (JSC::VM::updateStackLimits): (JSC::VM::updateStackLimit): Deleted. * runtime/VM.h: (JSC::VM::stackLimit): (JSC::VM::softStackLimit): (JSC::VM::addressOfSoftStackLimit): (JSC::VM::setCLoopStackLimit): (JSC::VM::isSafeToRecurse): (JSC::VM::lastStackTop): (JSC::VM::setException): * runtime/VMInlines.h: (JSC::VM::ensureStackCapacityFor): (JSC::VM::isSafeToRecurseSoft): (JSC::VM::shouldTriggerTermination): * tests/stress/promise-infinite-recursion-should-not-crash.js: Added. (testPromise): (promiseFunc): * yarr/YarrPattern.cpp: Tools: In http://trac.webkit.org/r203067, we limited the amount of stack that tests will run with to keep stack overflow tests sane. Turns out, we also need to teach the LayoutTestRelay to pass env vars over to the iOS simulator. This is needed in order to keep the js/regress-139548.html test happy with this patch. Also fixed up run_webkit_tests.py to explicitly pass an int size value for the JSC_maxPerThreadStackUsage option. Otherwise, it will pass a float value. * LayoutTestRelay/LayoutTestRelay/LTRelayController.m: (-[LTRelayController _environmentVariables]): * Scripts/webkitpy/layout_tests/run_webkit_tests.py: (main): LayoutTests: * js/regress-141098-expected.txt: * js/script-tests/regress-141098.js: (testEval): (probeAndRecurse): - Gave all the test constants names. - Tweaked the constants to allow the test to run in the least amount of time, and also to behave consistently across all test configurations. - Re-enable eager tests now that the test should finish quickly. Canonical link: https://commits.webkit.org/177842@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@203142 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-07-13 00:19:15 +00:00
Starting 1st probeAndRecurse
DFG JIT needs to check for stack overflow at the start of Program and Eval execution https://bugs.webkit.org/show_bug.cgi?id=141676 Reviewed by Filip Pizlo. Source/JavaScriptCore: Added stack check to the beginning of the code the DFG copmiler emits for Program and Eval nodes. To aid in testing the code, I replaced the EvalCodeCache::maxCacheableSourceLength const a options in runtime/Options.h. The test script, run-jsc-stress-tests, sets that option to a huge value when running with the "Eager" options. This allows the updated test to reliably exercise the code in questions. * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): Added stack check. * bytecode/EvalCodeCache.h: (JSC::EvalCodeCache::tryGet): (JSC::EvalCodeCache::getSlow): * runtime/Options.h: Replaced EvalCodeCache::imaxCacheableSourceLength with Options::maximumEvalCacheableSourceLength so that it can be configured when running the related test. Tools: Set the newly added --maximumEvalCacheableSourceLength option for eager test runs. This is needed to allow the eval out of stack tests to tier up. Without this option, we don't cache the likely large string expression that we want to eval. * Scripts/run-jsc-stress-tests: LayoutTests: Updated the check for out of stack at eval entry test from using a fixed number of frame to back track to now adjust the amount of back tracking up the stack based on where we can run a simple eval(). At that point in the stack we try to cause an out of stack exception. Also added a second pass of the test that takes the originally failing eval and tiers that eval expression up to the DFG when used with the agreessive options of run-jsc-stress-tests. This was done to reduce the amount of time the test takes to run in debug builds. * js/regress-141098-expected.txt: * js/script-tests/regress-141098.js: (testEval): (probeAndRecurse): Canonical link: https://commits.webkit.org/159861@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@180423 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-02-20 18:38:57 +00:00
PASS Exception: RangeError: Maximum call stack size exceeded.
We should use different stack limits for stack checks from JS and host code. https://bugs.webkit.org/show_bug.cgi?id=159442 <rdar://problem/26889188> Reviewed by Geoffrey Garen. Source/JavaScriptCore: We have 2 stack reservedZoneSizes: 1. Options::softReservedZoneSize() 2. Options::reservedZoneSize() Respectively, there are used to define 2 stack limits based on these reserved zone sizes: 1. VM::m_softStackLimit 2. VM::m_stackLimit Options::reservedZoneSize() is the amount of the stack space that JSC guarantees to the VM and client host code for it's use. Host code that has well known stack usage characteristics (i.e. doesn't call arbitrary code) may do stack checks against the VM::m_stackLimit limit (which is computed using Options::reservedZoneSize()). Options::softReservedZoneSize() is a more conservative amount of reserved stack space. This is used to compute the VM::m_softStackLimit limit. Any code that is difficult to have its stack usage characterized (i.e. may call arbitrary code) may need more stack space for its work. Hence, these should do stack checks against the VM::m_softStackLimit limit. JS code and host code that may call into JS code falls into the category of code that may call arbitrary code. Hence, they should do stack checks against the VM::m_softStackLimit limit. Accordingly, the VM now provides 2 recursion check functions: 1. VM::isSafeToRecurseSoft() will do a stack check against VM::m_softStackLimit. In addition, for C Loop builds, VM::isSafeToRecurseSoft() will also check the CLoopStack against VM::m_cloopStackLimit. 2. VM::isSafeToRecurse() will do a stack check against VM::m_stackLimit. Also added a promise-infinite-recursion-should-not-crash.js test. * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitNodeInTailPosition): (JSC::BytecodeGenerator::emitNodeInConditionContext): * interpreter/CLoopStack.cpp: (JSC::CLoopStack::grow): * interpreter/CLoopStack.h: (JSC::CLoopStack::size): * interpreter/CLoopStackInlines.h: (JSC::CLoopStack::ensureCapacityFor): (JSC::CLoopStack::isSafeToRecurse): (JSC::CLoopStack::topOfFrameFor): * interpreter/CachedCall.h: (JSC::CachedCall::CachedCall): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * parser/Parser.cpp: * runtime/Options.h: * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (JSC::ProxyObject::getOwnPropertySlotCommon): (JSC::ProxyObject::performPut): (JSC::performProxyCall): (JSC::performProxyConstruct): (JSC::ProxyObject::performDelete): (JSC::ProxyObject::performPreventExtensions): (JSC::ProxyObject::performIsExtensible): (JSC::ProxyObject::performDefineOwnProperty): (JSC::ProxyObject::performGetOwnPropertyNames): (JSC::ProxyObject::performSetPrototype): (JSC::ProxyObject::performGetPrototype): * runtime/RegExp.cpp: (JSC::RegExp::finishCreation): (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): * runtime/StringRecursionChecker.h: (JSC::StringRecursionChecker::performCheck): * runtime/VM.cpp: (JSC::VM::setStackPointerAtVMEntry): (JSC::VM::updateSoftReservedZoneSize): (JSC::preCommitStackMemory): (JSC::VM::updateStackLimits): (JSC::VM::updateStackLimit): Deleted. * runtime/VM.h: (JSC::VM::stackLimit): (JSC::VM::softStackLimit): (JSC::VM::addressOfSoftStackLimit): (JSC::VM::setCLoopStackLimit): (JSC::VM::isSafeToRecurse): (JSC::VM::lastStackTop): (JSC::VM::setException): * runtime/VMInlines.h: (JSC::VM::ensureStackCapacityFor): (JSC::VM::isSafeToRecurseSoft): (JSC::VM::shouldTriggerTermination): * tests/stress/promise-infinite-recursion-should-not-crash.js: Added. (testPromise): (promiseFunc): * yarr/YarrPattern.cpp: Tools: In http://trac.webkit.org/r203067, we limited the amount of stack that tests will run with to keep stack overflow tests sane. Turns out, we also need to teach the LayoutTestRelay to pass env vars over to the iOS simulator. This is needed in order to keep the js/regress-139548.html test happy with this patch. Also fixed up run_webkit_tests.py to explicitly pass an int size value for the JSC_maxPerThreadStackUsage option. Otherwise, it will pass a float value. * LayoutTestRelay/LayoutTestRelay/LTRelayController.m: (-[LTRelayController _environmentVariables]): * Scripts/webkitpy/layout_tests/run_webkit_tests.py: (main): LayoutTests: * js/regress-141098-expected.txt: * js/script-tests/regress-141098.js: (testEval): (probeAndRecurse): - Gave all the test constants names. - Tweaked the constants to allow the test to run in the least amount of time, and also to behave consistently across all test configurations. - Re-enable eager tests now that the test should finish quickly. Canonical link: https://commits.webkit.org/177842@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@203142 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-07-13 00:19:15 +00:00
Starting 2nd probeAndRecurse
DFG JIT needs to check for stack overflow at the start of Program and Eval execution https://bugs.webkit.org/show_bug.cgi?id=141676 Reviewed by Filip Pizlo. Source/JavaScriptCore: Added stack check to the beginning of the code the DFG copmiler emits for Program and Eval nodes. To aid in testing the code, I replaced the EvalCodeCache::maxCacheableSourceLength const a options in runtime/Options.h. The test script, run-jsc-stress-tests, sets that option to a huge value when running with the "Eager" options. This allows the updated test to reliably exercise the code in questions. * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): Added stack check. * bytecode/EvalCodeCache.h: (JSC::EvalCodeCache::tryGet): (JSC::EvalCodeCache::getSlow): * runtime/Options.h: Replaced EvalCodeCache::imaxCacheableSourceLength with Options::maximumEvalCacheableSourceLength so that it can be configured when running the related test. Tools: Set the newly added --maximumEvalCacheableSourceLength option for eager test runs. This is needed to allow the eval out of stack tests to tier up. Without this option, we don't cache the likely large string expression that we want to eval. * Scripts/run-jsc-stress-tests: LayoutTests: Updated the check for out of stack at eval entry test from using a fixed number of frame to back track to now adjust the amount of back tracking up the stack based on where we can run a simple eval(). At that point in the stack we try to cause an out of stack exception. Also added a second pass of the test that takes the originally failing eval and tiers that eval expression up to the DFG when used with the agreessive options of run-jsc-stress-tests. This was done to reduce the amount of time the test takes to run in debug builds. * js/regress-141098-expected.txt: * js/script-tests/regress-141098.js: (testEval): (probeAndRecurse): Canonical link: https://commits.webkit.org/159861@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@180423 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-02-20 18:38:57 +00:00
PASS Exception: RangeError: Maximum call stack size exceeded.
Google doc spreadsheet reproducibly crashes when sorting https://bugs.webkit.org/show_bug.cgi?id=141098 Reviewed by Oliver Hunt. Source/JavaScriptCore: Moved the stack check to before the callee registers are allocated in the prologue() by movving it from the functionInitialization() macro. This way we can check the stack before moving the stack pointer, avoiding a crash during a "call" instruction. Before this change, we weren't even checking the stack for program and eval execution. Made a couple of supporting changes. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_stack_check): We can't just go up one frame as we may be processing an exception to an entry frame. * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: (llint_throw_from_slow_path_trampoline): Changed method to get the vm from the code block to not use the codeBlock, since we may need to continue from an exception in a native function. LayoutTests: New test. * js/regress-141098-expected.txt: Added. * js/regress-141098.html: Added. * js/script-tests/regress-141098.js: Added. (probeAndRecurse): Canonical link: https://commits.webkit.org/159593@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@180060 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-02-13 18:57:57 +00:00
PASS successfullyParsed is true
TEST COMPLETE