WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
UNCONFIRMED
30331
Page with a form, five multi-line fields, large strings, Webkit RSIZE grows and grows
https://bugs.webkit.org/show_bug.cgi?id=30331
Summary
Page with a form, five multi-line fields, large strings, Webkit RSIZE grows a...
Rainer Joswig
Reported
2009-10-13 05:07:13 PDT
Hi, I am using Webkit, a nightly build. The process listing systems says 'Safari' (does it then really use Safari?). As an debugging example I have written a page with form which has five multi-line fields and a submit button. The fields have a default content of random strings of about 2 million characters each. So the page size is roughly five * 2 million characters. This is also the size on disk, if I save the form from the browser. The form page is dynamically generated by the server (no static text file). Transfer is HTTP 1.1. After about ten submissions of this form the memory footprint of Webkit goes in the direction of 1 GB and still grows. Both virtual and physical memory allocations of Webkit are in that range (the allocated physical memory is only a little smaller). My Macbook Pro (3 GB RAM, Mac OS X 10.6.1) eventually starts swapping and gets very slow during swapping. I don't know if the memory ever gets freed, from what I see the memory size of Webkit grows and grows. But even if it gets freed in some distant future, I would then prefer Webkit to release memory much more aggressively. So either this is a memory leak, or Webkit is not freeing/reusing memory early enough. The page is about ten MB in size, submitting it ten times should not bring the Webkit memory usage into the 1 GB RAM range. If somebody would like to have a look at it, I'd be happy to setup an example page. PID COMMAND %CPU TIME #TH #WQ #PORT #MREG RPRVT RSHRD RSIZE VPRVT VSIZE 0 submissions 66046 Safari 0.2 00:01.51 9 2 130 334 28M+ 23M 67M+ 203M 4858M 1 submission 66046 Safari 12.8 00:17.57 9 2 136- 433 306M- 24M 413M 513M 5289M 2 submissions 66046 Safari 14.1 00:33.96 9 2 139 475 429M 24M 591M 647M 5473M 3 submissions 66046 Safari 1.6 00:50.48 10 3 145+ 505 454M 24M 719M- 762M 5604M ... You can see that RSIZE is after three form submissions already at 719M. Regards, Rainer Joswig
Attachments
Add attachment
proposed patch, testcase, etc.
Mark Rowe (bdash)
Comment 1
2009-10-13 12:50:40 PDT
<
rdar://problem/7299794
>
Mark Rowe (bdash)
Comment 2
2009-10-13 13:11:26 PDT
(In reply to
comment #0
)
> Hi, > > I am using Webkit, a nightly build. The process listing systems says 'Safari' > (does it then really use Safari?).
Safari is the application. WebKit is the framework used by the application to render web content.
> As an debugging example I have written a page with form which has five > multi-line fields and a submit button. The fields have a default content of > random strings of about 2 million characters each. So the page size is roughly > five * 2 million characters. This is also the size on disk, if I save the form > from the browser. The form page is dynamically generated by the server (no > static text file). Transfer is HTTP 1.1.
Can you share the example page so that we can reproduce the scenario that you’re testing with? That should make it quite easy for us to reproduce the results and investigate the memory growth. Thanks for the bug report!
Rainer Joswig
Comment 3
2009-10-13 13:52:12 PDT
See this page:
http://www.cl-http.org:8002/large-form
It's a server running on a small Mac mini, so don't expect any performance wonders and I wrote a very stripped down page. The form page contains a submit button and five fields. For each field I list the number of characters on top. The string is static in this example and all fields have the same string content. The response page has a link back to the form and then prints the number of return fields and for each field the length of received data. Let me know if you have questions about the example.
Rainer Joswig
Comment 4
2009-10-13 13:57:55 PDT
I should mention that submitting the form really posts the ten MB data, so with a slow upstream connection it might take some time. With my ADSL line a post takes a minute or two.
Mark Rowe (bdash)
Comment 5
2009-10-13 14:02:16 PDT
Are you able to share the source of the dynamic page so that I could set up the same server locally to bypass the network overhead and ensure that we can test this even if your machine is not available?
Rainer Joswig
Comment 6
2009-10-13 14:46:17 PDT
the server machine is a separate Mac mini running all the time and should be available, it is itself not behind ADSL. If you have a fast network access (which Apple sure has ;-) ) , the performance should be no problem at your side. The server and the page generation code is written in Lisp (it is a PPC application currently), so not that helpful if only Apache/etc. knowhow is available. If you really really really really want to run it locally, I could make that PPC application available.
Darin Adler
Comment 7
2010-11-09 16:16:34 PST
I assume the format data is all sitting in the back/forward list so we can resubmit the form. Do other browsers perform better?
Darin Adler
Comment 8
2010-11-09 16:16:45 PST
form data, not format data
Darin Adler
Comment 9
2010-11-09 16:17:16 PST
Oh, I see, 10MB times 10 is not 1GB.
Darin Adler
Comment 10
2010-11-09 16:24:52 PST
I suspect what we are seeing here is simply due to multiple copies of the large rendering tree that are kept around due to back/forward caching. If we tried the same experiment closing the window each time I suspect we would not see the memory growth.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug