RESOLVED DUPLICATE of bug 17534 27041
AJAX memory leak when sending out requests
https://bugs.webkit.org/show_bug.cgi?id=27041
Summary AJAX memory leak when sending out requests
Rashad Itani
Reported 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)
Attachments
test file to reproduce the memory issue in webkit (2.16 KB, application/zip)
2009-07-07 14:06 PDT, Rashad Itani
no flags
Top listing at Safari Start (99.89 KB, image/png)
2009-11-21 23:23 PST, mark
no flags
After 2 hours top listing (112.61 KB, image/png)
2009-11-21 23:28 PST, mark
no flags
mark
Comment 1 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.
Alexey Proskuryakov
Comment 2 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 ***
mark
Comment 3 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
mark
Comment 4 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
mark
Comment 5 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
mark
Comment 6 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
Alexey Proskuryakov
Comment 7 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.
Note You need to log in before you can comment on or make changes to this bug.