Bug 17534 – Every XMLHttpRequest leaks memory, at least for Safari Activity window

• Status: RESOLVED
• Resolution: INVALID
• Component: New Bugs

[James Berry]

Each time XMLHttpRequest is issued, a new entry is generated in the Safari Activity window. For regular periodic updates of an open page, this could accumulate significantly over time.

The attached test issues an XMLHttpRequest to google, once a second. Each second, you'll note that a new entry is added to the Safari Activity window for the http://www.google.com url.

I don't know if this memory leak is limited to only the Safari Activity items, or if it reaches farther. Nor do I know how big the leak is.

I don't believe it would be wrong behavior, necessarily, if an activity window record replaced any previous record for the same url???

[James Berry]

Created attachment 19350 [details]
Page which makes a request every second, illustrating the leak.

[Geoffrey Garen]

<rdar://problem/5292635>

[James Berry]

Maybe that attached test only works when opened as a local file url, because otherwise it becomes a cross-site request and is therefore illegal.

[Mike Wilson]

I have also seen major memory growth (in excess of 100MB) in both Safari 2.0.4 and 3.0.4 when doing a lot of XHR calls. It seems memory growth is proportional to the number of XHR calls and size of replies, so I am thinking that the Activity feature maybe is caching the replies? 
Is it so, and can this feature then be disabled? 

[Mike Wilson]

Created attachment 19778 [details]
Test case html/script file

This html page lets you send 1000 XHR requests to fetch the associated data file. Click the "1000" button and check Safari's memory usage.

[Mike Wilson]

Created attachment 19779 [details]
Test case data text file

Associated data file. Put both files in the same directory on a web server and navigate to the html file.

[Alexey Proskuryakov]

The Activity window is handled by Safari application, and as such is out of scope for the open source WebKit project.

(In reply to comment #5)

> This html page lets you send 1000 XHR requests to fetch the associated data
> file. Click the "1000" button and check Safari's memory usage.

I can see that memory usage grows by 50 MB, but this memory is reclaimed after garbage collection in TOT. Safari 3.0.4 with its default WebKit does seem to have the problem indeed (I do not think it is caused by the Activity window though).

Could you please verify your results with a nightly build (http://nightly.webkit.org)?

[Mike Wilson]

After running more tests it seems Safari 3 and nightly webkits "stabilize" after the first run. A fair bit of growth is seen on the first run but after that it doesn't get worse. It's a different story for Safari 2 though. I missed testing several consecutive runs on Safari 3 before reporting, sorry about that.
Anyway, my figures are below. All run data is specified as
  MB before test -> MB after test -> MB after GC
I also added an asynchronous variant of the x1000 test.

Safari 2.0.4 Mac (419.3)
- 1000 XHR synchronous:
  run1: 13->126->115(peak at 216)
  run2: 115->192->194(peak at 284)
  run3: 194->273->248(peak at 342)
- 1000 XHR asynchronous
  run1: 13->63->56(peak at 139)
  run2: 56->89->84(peak at 170)
  run3: 84->122->112(peak at 212)

Safari 3.0.4 Mac (523.10.3)
- 1000 XHR synchronous:
  run1: 15->126->78
  run2: 78->133->81
  run3: 81->135->83

Safari 3.0.4 Win (523.15)
- 1000 XHR synchronous:
  run1: 35->122->76
  run2: 76->127->77
  run3: 77->124->74
- 1000 XHR asynchronous
  run1: 36->64->34
  run2: 34->68->41
  run3: 41->94->41

WebKit nightly Win (r30881)
- 1000 XHR synchronous
  run1: 37->145->102
  run2: 102->153->104
  run3: 104->151->104
- 1000 XHR asynchronous
  run1: 37->62->40
  run2: 40->91->38
  run3: 38->92->38

[John Kjellberg]

I have the same problem. The "mem usage" in Windows Task Manager keeps on growing when running the script with "Safari 4 Public Beta (528.17)". I stopped when it reached 300MB. When leaving the page the memory isn't released. The list in the "activity" windows no longer show the items.

I have also tried it with home built Midori 0.1.6 and "WebKit-r43758.tar.bz2" in linux with PPC processor. It also increases memory usage with time. According to "/proc/<pid>/smaps" it is the "[heap]" memory of type "Rss"/"Private_Dirty"/"Referenced" that is eaten.

[Alexey Proskuryakov]

*** Bug 27041 has been marked as a duplicate of this bug. ***

[Sergio Villar Senin]

Any update on this? Google's instant search makes us leak tons of XMLHttpRequests

[Alexander Casassovici]

This bug also impacts chrome on snow leopard and mobile safari on ios 5.1 (and probably heaps of other platforms)

In our particular case, since I get a heavy json (15M), 100 requests are enough to get mobile safari to crash on iPad with the following code :

http://pastie.org/3966694

[Alexander Casassovici]

(In reply to comment #12)
> This bug also impacts chrome on snow leopard and mobile safari on ios 5.1 (and probably heaps of other platforms)
> 
> In our particular case, since I get a heavy json (15M), 100 requests are enough to get mobile safari to crash on iPad with the following code :
> 
> http://pastie.org/3966694

(was lion / not SL - won't matter anyway I guess)

Also obviously the isssue is memory leaking: the chrome process jumps to 1Gb ram and then crashes

[Simon Fraser (smfr)]

Does this still occur in recent WebKit nightly builds?

[Alexey Proskuryakov]

Alexander, this bug is about using memory for Safari Activity window. Mobile Safari doesn't have it, and Chrome is not Safari.

Please file a new bug with a complete test case (the paste.org test doesn't have explore_data.js).

[Brian Holt]

I have been investigating this leak in the context of WebKitGTK and have come to the conclusion that there is no leak and that any increase in the heap size due to XMLHttpRequests are because the garbage collector is not firing.

However, if garbage collection is forced by reloading the web page then all memory is recovered.

This chart from massif shows the heap profile for the attached test case, with 1000 XHRs (50MB), followed by a reload of the page, another 1000 XHRs and a final reload.

    MB
57.75^                                                                     #  
     |                                :@                                 ::#  
     |                              :@:@                               ::::#  
     |                             ::@:@::                           ::@:::#  
     |                          @::::@:@:                          ::::@:::#  
     |                        @@@: ::@:@:                         :::::@:::#  
     |                       @@ @: ::@:@:                       @::::::@:::#  
     |                     @:@@ @: ::@:@:                      :@::::::@:::#  
     |                   @:@:@@ @: ::@:@:                    :::@::::::@:::#: 
     |                 ::@:@:@@ @: ::@:@:                 :::: :@::::::@:::#: 
     |               @@: @:@:@@ @: ::@:@:               ::: :: :@::::::@:::#: 
     |              @@@: @:@:@@ @: ::@:@:              :: : :: :@::::::@:::#: 
     |           :::@@@: @:@:@@ @: ::@:@:             ::: : :: :@::::::@:::#: 
     |          @: :@@@: @:@:@@ @: ::@:@:           ::::: : :: :@::::::@:::#::
     |        ::@: :@@@: @:@:@@ @: ::@:@: :       :@: ::: : :: :@::::::@:::#::
     |      @@::@: :@@@: @:@:@@ @: ::@:@: :     :::@: ::: : :: :@::::::@:::#::
     |     :@@::@: :@@@: @:@:@@ @: ::@:@: :   ::: :@: ::: : :: :@::::::@:::#::
     |  :@@:@@::@: :@@@: @:@:@@ @: ::@:@: : ::::: :@: ::: : :: :@::::::@:::#::
     | ::@ :@@::@: :@@@: @:@:@@ @: ::@:@: ::::::: :@: ::: : :: :@::::::@:::#::
     | ::@ :@@::@: :@@@: @:@:@@ @: ::@:@: : ::::: :@: ::: : :: :@::::::@:::#::
   0 +----------------------------------------------------------------------->GB
     0                                                                   1.441

[Anne van Kesteren]

INVALID per last comment and lack of follow-up.