[Webkit-unassigned] [Bug 147403] New: web process continually eating memory on simple, shared Google Docs spreadsheet

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=147403

            Bug ID: 147403
           Summary: web process continually eating memory on simple,
                    shared Google Docs spreadsheet
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: Macintosh
                OS: Mac OS X 10.10
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: dev+webkit at mattlilek.com

Created attachment 257739
  --> https://bugs.webkit.org/attachment.cgi?id=257739&action=review
Really simple sheet example

Loading a simple, shared Google Docs spreadsheet and leaving it open causes the web process to steadily consume more and more memory with only a small amount of leaks showing up in the `leaks` tool. Encountered this today after leaving a stupidly simple shared spreadsheet open in a tab on my work laptop.

Filing here instead of Radar for easier back & forth since, unfortunately, I can't seem to get a ton of good data on what's actually happening here. The `leaks` tool tells me that the web process is marked CS_RESTRICT so I'm not sure if it's giving me everything and the Allocations instrument won't attach, presumably for the same reason.

I'm not sure whether the steps that add content are necessary to reproduce this, but ¯\_(ツ)_/¯.

* STEPS TO REPRODUCE
1. Open https://docs.google.com/spreadsheets
2. Click the (+) in the bottom right corner to create a new, blank spreadsheet.
3. Add some simple text on the first couple of cells in the first column.
4. Create a second sheet using the + button in the lower left corner and add similar content to the first sheet.
5. Share the document with a couple of other people.
6. In another browser or on another machine, open the shared sheet from a different account. Repeat this twice.

After just a few minutes, the memory use went from ~350 MB when the page was initially loaded to ~700 MB. While not the most accurate and useful info and assuming leaks can be trusted on my machine, this is the kind of growth I was seeing with the above repro steps, just letting it sit there, once or twice adding a new line of content to the sheet (i.e.: between the last two entries below):

Launch Time:     2015-07-28 22:10:48.901 -0700
Date/Time:  2015-07-28 22:11:16.432 -0700    Process 1130: 26305 nodes malloced for 121329 KB
Date/Time:  2015-07-28 22:11:31.692 -0700    Process 1130: 66790 nodes malloced for 404615 KB
Date/Time:  2015-07-28 22:12:42.172 -0700    Process 1130: 66071 nodes malloced for 495008 KB
Date/Time:  2015-07-28 22:16:11.218 -0700    Process 1130: 67538 nodes malloced for 740611 KB
Date/Time:  2015-07-28 22:19:10.272 -0700    Process 1130: 71327 nodes malloced for 954714 KB
Date/Time:  2015-07-28 22:33:30.477 -0700    Process 1130: 76714 nodes malloced for 1873688 KB
Date/Time:  2015-07-28 22:38:46.192 -0700    Process 1130: 78128 nodes malloced for 2561626 KB
Date/Time:  2015-07-28 22:49:17.383 -0700    Process 1130: 73528 nodes malloced for 2616807 KB
Date/Time:  2015-07-28 22:56:17.250 -0700    Process 1130: 85116 nodes malloced for 3177611 KB

When I noticed this on my machine earlier today, activity monitor claimed the web process was eating 4.3GB of memory. That was on 10.10.5 (14F6a) on a 2015, 13" Retina MBP with Safari 9.0 (10601.1.39.0.2) and tonight I reproduced using the steps above on a 2013 iMac running 10.11 (15A235d) with Safari 9.0 (11601.1.41). The other two accounts were on the same iMac in Chrome 44.0.2403.89 which didn't have any noticeable memory growth over the same time.

FWIW, `leaks` does show a number of small RTCReporting leaks for a grand total of 7360 leaked bytes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150729/2e12bac7/attachment-0001.html>