Enrique Reporter
	Description • 9 years ago

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150511103818

Steps to reproduce:

Execute the script:
<script>
    URL="http://127.0.0.1:44554/non_existing_server.html";
    var http = new XMLHttpRequest();
    function UrlExists()
    {   
        http.open('HEAD', URL);
        http.onreadystatechange = function() {
          if (this.status >= 200 && this.status < 300) {
              window.location.replace(URL);
              return;
          }
          setTimeout(UrlExists, 4000);
        };
        http.send();
    }   
    UrlExists();
</script>



Actual results:

The script runs "OK" for about 40 seconds. After that, Firefox main thread start to consume lot of CPU and RAM. The GUI freezes. Must "kill -9" Firefox to exit.


Expected results:

The script must run forever with no issues (works OK on Google Chromium).

	Loic
	Comment 1 • 9 years ago

Some old versions don't have the memory leak after 30-40 sec, and I found it regressed. I'm not sure if it's valid or not anyway.

good=2012-03-26
bad=2012-03-27
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ba4983d9c1f9&tochange=c3cb87871829

Suspected:
Jonas Sicking — Bug 301705: Don't throw when XMLHttpRequest.status is gotten too early. r=bz

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 2 • 9 years ago

Bug 301705 probably simply caused this testcase to actually run. Before bug 301705 we probably simply threw an exception right away and never got to the setTimeout part. So I doubt that bug 301705 is the cause of the leak.

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 3 • 9 years ago

Adding Olli who does more XHR work than me these days.

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 9 years ago

Here's a simpler version of this testcase in Firefox:

  function foo() {
    setTimeout(foo, 4000);
    setTimeout(foo, 4000);
  }
  foo();

The reason for that is that the XHR first transitions to the HEADERS_RECEIVED state then the DONE state.  The testcase is not checking that readyState == DONE, so it does the setTimeout call twice.  What this means is that every 4 seconds the number of timers involved doubles.  After 40 seconds we're dealing with 1024 timers, and after that things quickly get out of hand.

In Chrome, this same testcase only seems to have a single readystate transition to DONE, so there is no exponential growth in number of timers there.

Looking at the XHR spec, it's not clear to me that we should ever be going into the HEADERS_RECEIVED state here.  Perhaps that bit in nsXMLHttpRequest::OnStartRequest should be conditioned on !mErrorLoad?

	Andrew McCreight [:mccr8]
	Comment 5 • 9 years ago

It sounds like the memory usage is just an incidental consequence of differing XHR behavior, so I'm going to remove the MemShrink tag.

	Enrique Reporter
	Comment 6 • 9 years ago

I tested activating multiprocess to see how it affects other tabs. No luck! 

The main firefox process CPU ussage "grows" up to 180%, while the "Web Content" process ussage "grows" up to 100-120%. 

Time to time the message "A web page is causing Firefox Developer Edition to slow ..." appears. I click on "Stop script" but it doesn't solve the problem. Only killing and restarting fix the problem.