Bug 17534

Summary: Every XMLHttpRequest leaks memory, at least for Safari Activity window
Product: WebKit Reporter: James Berry <james>
Component: New BugsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: alex, annevk, ap, brian.holt, chris, jchaffraix, john.kjellberg, mikewse, noel.vellemans, rashaditani, simon.fraser, svillar
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.5   
Attachments:
Description Flags
Page which makes a request every second, illustrating the leak.
none
Test case html/script file
none
Test case data text file none

Description James Berry 2008-02-25 09:40:16 PST
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???
Comment 1 James Berry 2008-02-25 09:41:24 PST
Created attachment 19350 [details]
Page which makes a request every second, illustrating the leak.
Comment 2 Geoffrey Garen 2008-02-25 11:01:57 PST
<rdar://problem/5292635>
Comment 3 James Berry 2008-02-25 11:13:14 PST
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.
Comment 4 Mike Wilson 2008-03-14 16:06:28 PDT
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? 
Comment 5 Mike Wilson 2008-03-14 16:08:59 PDT
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.
Comment 6 Mike Wilson 2008-03-14 16:10:26 PDT
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.
Comment 7 Alexey Proskuryakov 2008-03-17 02:25:02 PDT
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)?
Comment 8 Mike Wilson 2008-03-19 08:43:16 PDT
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
Comment 9 John Kjellberg 2009-05-19 06:46:43 PDT
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.
Comment 10 Alexey Proskuryakov 2009-11-21 18:39:33 PST
*** Bug 27041 has been marked as a duplicate of this bug. ***
Comment 11 Sergio Villar Senin 2012-05-25 03:40:56 PDT
Any update on this? Google's instant search makes us leak tons of XMLHttpRequests
Comment 12 Alexander Casassovici 2012-05-25 08:57:02 PDT
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
Comment 13 Alexander Casassovici 2012-05-25 08:58:40 PDT
(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
Comment 14 Simon Fraser (smfr) 2012-05-25 09:28:22 PDT
Does this still occur in recent WebKit nightly builds?
Comment 15 Alexey Proskuryakov 2012-05-25 10:08:28 PDT
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).
Comment 16 Brian Holt 2013-06-28 02:13:40 PDT
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
Comment 17 Anne van Kesteren 2023-05-12 23:00:38 PDT
INVALID per last comment and lack of follow-up.