Bug 30331 - Page with a form, five multi-line fields, large strings, Webkit RSIZE grows and grows
Summary: Page with a form, five multi-line fields, large strings, Webkit RSIZE grows a...
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.6
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar, NeedsReduction
Depends on:
Blocks:
 
Reported: 2009-10-13 05:07 PDT by Rainer Joswig
Modified: 2010-11-09 16:24 PST (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Joswig 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
Comment 1 Mark Rowe (bdash) 2009-10-13 12:50:40 PDT
<rdar://problem/7299794>
Comment 2 Mark Rowe (bdash) 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!
Comment 3 Rainer Joswig 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.
Comment 4 Rainer Joswig 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.
Comment 5 Mark Rowe (bdash) 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?
Comment 6 Rainer Joswig 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.
Comment 7 Darin Adler 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?
Comment 8 Darin Adler 2010-11-09 16:16:45 PST
form data, not format data
Comment 9 Darin Adler 2010-11-09 16:17:16 PST
Oh, I see, 10MB times 10 is not 1GB.
Comment 10 Darin Adler 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.