Drop of performance between FF31 and FF32 when executing a regexp

RESOLVED WONTFIX

Status

()

Core
JavaScript Engine
--
critical
RESOLVED WONTFIX
3 years ago
3 years ago

People

(Reporter: Mickaël Hoareau, Unassigned)

Tracking

({hang, regression})

32 Branch
x86_64
All
hang, regression
Points:
---

Firefox Tracking Flags

(firefox32 wontfix, firefox33 ?, firefox34 ?, firefox35 ?)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140830210550

Steps to reproduce:

Display a script, for exemple : 
https://developer.cdn.mozilla.net/media/js/main-min.js?build=db5035d

Activate the developer tools.

In the JS console copy/paste the following portion of code (I've simplified to a maximum to only let the problematic part of the regexp) :

test = "((\\S|\\s)+;\\s*\\n){10,}";
reg = new RegExp(test, "i");
reg.test(document.body.innerHTML)

The brower becomes unresponsive and finally ask for stopping the execution of the script.

The same code execution in FF 31 and above terminates quickly (less than a second).


Actual results:

The browser froze.


Expected results:

It should return true/false quickly (less than 1 second)

Updated

3 years ago
Blocks: 976446
Severity: normal → critical
Component: Untriaged → JavaScript Engine
Keywords: hang, regression
OS: Linux → All
Product: Firefox → Core
status-firefox32: --- → wontfix
status-firefox33: --- → ?
status-firefox34: --- → ?
status-firefox35: --- → ?
Keywords: regressionwindow-wanted
The regression windows is already known and better, Alice775 identified bug 976446 as the cause.

I can confirm this with this regression range (only central builds used)
Last good revision: 58c5a3427997 (2014-05-16)
First bad revision: 2893f60d5903 (2014-05-17)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=58c5a3427997&tochange=2893f60d5903
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regressionwindow-wanted
I believe that this is one of a class of regexp that used to work incorrectly in the old regexp implementation.

That is, it terminated quickly, but gave the wrong answer because it didn't actually perform the matching; it just gave up after a bit and assumed "doesn't match" even if it actually was supposed to match.

You can see that clearly with this more-reduced testcase:

  test = "(.*;.*){10,}";
  reg = new RegExp(test, "i");
  reg.test(document.body.innerHTML)

this returns false in Firefox 31, whereas the correct return value is clearly true.
And to make it very clear, try this script with your other steps to reproduce in both Firefox 31 and Firefox 32:

  test = "(.*;.*){5,}";
  reg = new RegExp(test, "i");
  reg.test(document.body.innerHTML)
This really reminds me of another bug: bug 953013. Apparently we had another such case :0. Though that shouldn't surprise me.
> This really reminds me of another bug: bug 953013.

Yes, exactly.  This bug report is precisely about the sort of regexp that bug 953013 was about.

The irregexp landing fixed bug 953013 but at the cost of slow regexps effectively running forever (modulo the sclow script dialog) instead of terminating with an incorrect return value.

Comment 6

3 years ago
This seems pretty serious.  I'm still trying to isolate it, but some expressions that have been running for a while are causing high cpu usage/lockups.  I don't suppose it is possible to compile with YARR still, is it?
(In reply to Adam Moore from comment #6)
> This seems pretty serious.  I'm still trying to isolate it, but some
> expressions that have been running for a while are causing high cpu
> usage/lockups.  I don't suppose it is possible to compile with YARR still,
> is it?

It's annoying, yes. There isn't anything we can do about it, though: these regexp's really are broken and only ever *seemed* to work in browsers that use Yarr. It's not possible at this point to compile Firefox with Yarr, and we have no intent whatsoever to return to using it; why would we restore broken behavior?

If you want to learn more about the background of all this, please read through the comments in bug 953013, or just the blog post that's linked to in that bug.

Marking this bug WONTFIX to reflect reality. If specific sites are seriously affected, individual evangelism bugs should be filed for those.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.