⚠ Archived content — this site is no longer maintained.   Current WebKit documentation is at docs.webkit.org.

Changeset 242955 in webkit


Ignore:
Timestamp:
Mar 14, 2019, 12:31:52 PM (7 years ago)
Author:
msaboff@apple.com
Message:

ASSERTION FAILED: regexp->isValid() or ASSERTION FAILED: !isCompilationThread()
https://bugs.webkit.org/show_bug.cgi?id=195735

Reviewed by Mark Lam.

JSTests:

New regression test.

  • stress/dont-strength-reduce-regexp-with-compile-error.js: Added.

(foo):
(bar):

Source/JavaScriptCore:

There are two bug fixes here.

The first bug happens due to a race condition when we are compiling on a separate thread while the
main thread is compiling the RegExp at a place where it can run out of stack. When that happens,
the RegExp becomes invalid due to the out of stack error. If we check the ASSERT condition in the DFG
compilation thread, we crash. After the main thread throws an exception, it resets the RegExp as
it might compile successfully the next time we try to execute it on a shallower stack.
The main thread will see the regular expression as valid when it executes the JIT'ed code we are compiling
or any slow path we call out to. Therefore ASSERTs like this in compilation code can be eliminated.

The second bug is due to incorrect logic when we go to run the regexp in the Strength Reduction phase.
The current check for "do we have code to run the RegExp?" only checks that the RegExp's state
is != NotCompiled. We also can't run the RegExp if there the state is ParseError.
Changing hasCode() to take this into account fixes the second issue.

(JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):

  • runtime/RegExp.h:
  • dfg/DFGSpeculativeJIT.cpp:

(JSC::DFG::SpeculativeJIT::compileNewRegexp):

  • runtime/RegExp.h:
Location:
trunk
Files:
1 added
5 edited

Legend:

Unmodified
Added
Removed
  • trunk/JSTests/ChangeLog

    r242954 r242955  
     12019-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
    1142019-03-14  Saam barati  <sbarati@apple.com>
    215
  • trunk/Source/JavaScriptCore/ChangeLog

    r242954 r242955  
     12019-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
    1292019-03-14  Saam barati  <sbarati@apple.com>
    230
  • trunk/Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp

    r242954 r242955  
    97579757{
    97589758    RegExp* regexp = node->castOperand<RegExp*>();
    9759     ASSERT(regexp->isValid());
    97609759
    97619760    GPRTemporary result(this);
  • trunk/Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp

    r242954 r242955  
    1127511275        LValue lastIndex = lowJSValue(m_node->child1());
    1127611276        ASSERT(regexp->cell()->inherits<RegExp>(vm()));
    11277         ASSERT(m_node->castOperand<RegExp*>()->isValid());
    1127811277
    1127911278        LBasicBlock slowCase = m_out.newBlock();
  • trunk/Source/JavaScriptCore/runtime/RegExp.h

    r242699 r242955  
    109109    bool hasCode()
    110110    {
    111         return m_state != NotCompiled;
     111        return m_state == JITCode || m_state == ByteCode;
    112112    }
    113113
Note: See TracChangeset for help on using the changeset viewer.