Changeset 242955 in webkit
- Timestamp:
- Mar 14, 2019, 12:31:52 PM (7 years ago)
- Location:
- trunk
- Files:
-
- 1 added
- 5 edited
-
JSTests/ChangeLog (modified) (1 diff)
-
JSTests/stress/dont-strength-reduce-regexp-with-compile-error.js (added)
-
Source/JavaScriptCore/ChangeLog (modified) (1 diff)
-
Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp (modified) (1 diff)
-
Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp (modified) (1 diff)
-
Source/JavaScriptCore/runtime/RegExp.h (modified) (1 diff)
Legend:
- Unmodified
- Added
- Removed
-
trunk/JSTests/ChangeLog
r242954 r242955 1 2019-03-13 Michael Saboff <msaboff@apple.com> 2 3 ASSERTION FAILED: regexp->isValid() or ASSERTION FAILED: !isCompilationThread() 4 https://bugs.webkit.org/show_bug.cgi?id=195735 5 6 Reviewed by Mark Lam. 7 8 New regression test. 9 10 * stress/dont-strength-reduce-regexp-with-compile-error.js: Added. 11 (foo): 12 (bar): 13 1 14 2019-03-14 Saam barati <sbarati@apple.com> 2 15 -
trunk/Source/JavaScriptCore/ChangeLog
r242954 r242955 1 2019-03-14 Michael Saboff <msaboff@apple.com> 2 3 ASSERTION FAILED: regexp->isValid() or ASSERTION FAILED: !isCompilationThread() 4 https://bugs.webkit.org/show_bug.cgi?id=195735 5 6 Reviewed by Mark Lam. 7 8 There are two bug fixes here. 9 10 The first bug happens due to a race condition when we are compiling on a separate thread while the 11 main thread is compiling the RegExp at a place where it can run out of stack. When that happens, 12 the RegExp becomes invalid due to the out of stack error. If we check the ASSERT condition in the DFG 13 compilation thread, we crash. After the main thread throws an exception, it resets the RegExp as 14 it might compile successfully the next time we try to execute it on a shallower stack. 15 The main thread will see the regular expression as valid when it executes the JIT'ed code we are compiling 16 or any slow path we call out to. Therefore ASSERTs like this in compilation code can be eliminated. 17 18 The second bug is due to incorrect logic when we go to run the regexp in the Strength Reduction phase. 19 The current check for "do we have code to run the RegExp?" only checks that the RegExp's state 20 is != NotCompiled. We also can't run the RegExp if there the state is ParseError. 21 Changing hasCode() to take this into account fixes the second issue. 22 23 (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp): 24 * runtime/RegExp.h: 25 * dfg/DFGSpeculativeJIT.cpp: 26 (JSC::DFG::SpeculativeJIT::compileNewRegexp): 27 * runtime/RegExp.h: 28 1 29 2019-03-14 Saam barati <sbarati@apple.com> 2 30 -
trunk/Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
r242954 r242955 9757 9757 { 9758 9758 RegExp* regexp = node->castOperand<RegExp*>(); 9759 ASSERT(regexp->isValid());9760 9759 9761 9760 GPRTemporary result(this); -
trunk/Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
r242954 r242955 11275 11275 LValue lastIndex = lowJSValue(m_node->child1()); 11276 11276 ASSERT(regexp->cell()->inherits<RegExp>(vm())); 11277 ASSERT(m_node->castOperand<RegExp*>()->isValid());11278 11277 11279 11278 LBasicBlock slowCase = m_out.newBlock(); -
trunk/Source/JavaScriptCore/runtime/RegExp.h
r242699 r242955 109 109 bool hasCode() 110 110 { 111 return m_state != NotCompiled;111 return m_state == JITCode || m_state == ByteCode; 112 112 } 113 113
Note:
See TracChangeset
for help on using the changeset viewer.