1070935 - Drop of performance between FF31 and FF32 when executing a regexp

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Mickaël Hoareau]

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)

Comment 1

[Matthias Versen [:Matti]]

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

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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)

Comment 4

[Hannes Verschore [:h4writer]]

This really reminds me of another bug: bug 953013. Apparently we had another such case :0. Though that shouldn't surprise me.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> 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

[Adam Moore]

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?

Comment 7

[Till Schneidereit [:till]]

(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.