Bug 27041

Summary: AJAX memory leak when sending out requests
Product: WebKit Reporter: Rashad Itani <rashaditani>
Component: New BugsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Critical CC: ap, mark
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Mac (Intel)   
OS: OS X 10.5   
Attachments:
Description Flags
test file to reproduce the memory issue in webkit
none
Top listing at Safari Start
none
After 2 hours top listing none

Description Rashad Itani 2009-07-07 14:06:29 PDT
Created attachment 32392 [details]
test file to reproduce the memory issue in webkit

When making ajax requests, there seems to be an issue in clearing out memory once the request is complete. I've attached some sample code to reproduce the problem. When using other browsers and our same sample code, we don't see the constant ramp up in memory usage. 

To Reproduce:

- Download the attached sample code and drop into any webserver.
- Enter the url for the textAjax.html file in the Webkit browser or app using webkit.
- Using top from a shell, you will constantly see memory ramp up and not be released (rprvt and rsize)
Comment 1 mark 2009-11-21 00:01:08 PST
My webapp sends 3 requests per second to stay in sync with the back-end.  Webkit dies a fast death when left running for very long.  Please look into this as it's killing my application and my customers are very upset.
Comment 2 Alexey Proskuryakov 2009-11-21 18:39:33 PST
This report doesn't have any information about how fast memory usage grows. When running the attached test in Safari 4.0.4, I only see a very small increase in memory use with time, which can be attributed to Activity window.

*** This bug has been marked as a duplicate of bug 17534 ***
Comment 3 mark 2009-11-21 23:23:53 PST
Created attachment 43671 [details]
Top listing at Safari Start

Top screen capture at Safari startup.

I then loaded my AJAX test and did one AJAX call every .750 seconds.

After only a couple of hours Safari was very unresponsive (my guess is the debugger console was too full of AJAX lines) and the top numbers for Safari had incremented greatly.

Start: #prts-142 $mregs-674 rprvt-99m rshrd-28m rsize-131m vsize-496m

After about and hour: #prts-151 #mregs-1600 rprvt-136m rshrd38m rsize-214m vsize-577m

The numbers are ever increasing over time with no plateau.

Hope this helps.
-ml
Comment 4 mark 2009-11-21 23:28:49 PST
Created attachment 43672 [details]
After 2 hours top listing

Here is the image of top when I stopped Safari.

My hope is that we can find and fix this as I have a large set of govt labs deploying a nationwide system that depends on Safari. We need to have the  ability to have Safari running full time in a control and logging solution without it locking up or crashing.  We must restart Safari often to keep this from becoming a problem.  But that is intrusive of the application.

Please let me know if there is something I can assist with in tracking this down or solving the problem.

Thanks,
-ml
Comment 5 mark 2009-11-22 09:38:01 PST
I turned off debugging and commented out the lines in the inspector that log to the activity log.

It would seem that the activity log my not be the culprit.

Here are Safari lines from top over time:

PID   COMMAND %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD RSIZE  VSIZE
85774 Safari  0.3% 0:06.95   9  142   684    92M    24M   132M   496M - start
85774 Safari  3.5% 2:02.41  12  160-  1038   113M+  30M   163M+  530M  - 1 hour
85774 Safari  6.2% 38:52.43 13  161-  1418   148M+  30M   251M+  623M
Comment 6 mark 2009-11-22 11:30:26 PST
If I leave Safari running for a few hours doing one ajax get request every second, I can't open the web inspector without Safari locking up, making my fan run on high and not responding.  I have to force quit.

-ml
Comment 7 Alexey Proskuryakov 2009-11-22 12:13:24 PST
Besides the Web Inspector, there is Safari Activity window, which also takes a little amount of memory on each request.

Your case might be different - if you could make a self-contained test case that we could run here, it would be useful.