1479864 - High memory usage after uploading many small files via S3 web UI

Status: RESOLVED INCOMPLETE

(Core :: DOM: Core & HTML, defect)

Description

[Tyson Smith [:tsmith]]

Attachment: memory-report.json.gz

Uploading about 950 small files (~255KB total) to S3 via the web ui (https://s3.console.aws.amazon.com/s3/buckets...) trigger high memory usage ~7.5GB. Once the transfer was complete the memory usage did not return to normal.

I tried triggering GC and CC in about memory and the only made a minor change in the usage.

Comment 1

[Nathan Froyd [:froydnj]]

The parent process has:

├──3,523.98 MB (69.65%) -- window-objects
│  ├──3,488.15 MB (68.95%) -- top(<anonymized-17179869679>, id=17179869670)
│  │  ├──3,437.29 MB (67.94%) -- active/window(<anonymized-17179869679>)
│  │  │  ├──2,384.60 MB (47.13%) -- dom
│  │  │  │  ├──2,379.13 MB (47.02%) ── orphan-nodes
│  │  │  │  └──────5.47 MB (00.11%) ++ (5 tiny)
│  │  │  ├──1,039.91 MB (20.55%) -- js-realm(<anonymized-2>)
│  │  │  │  ├──1,037.06 MB (20.50%) -- classes
│  │  │  │  │  ├────266.93 MB (05.28%) -- class(Array)/objects
│  │  │  │  │  │    ├──235.59 MB (04.66%) ── gc-heap
│  │  │  │  │  │    └───31.33 MB (00.62%) ++ malloc-heap
│  │  │  │  │  ├────248.11 MB (04.90%) -- class(Object)/objects
│  │  │  │  │  │    ├──127.35 MB (02.52%) -- malloc-heap
│  │  │  │  │  │    │  ├───92.64 MB (01.83%) ── slots
│  │  │  │  │  │    │  └───34.71 MB (00.69%) ── elements/normal
│  │  │  │  │  │    └──120.77 MB (02.39%) ── gc-heap
│  │  │  │  │  ├────188.31 MB (03.72%) ++ (17 tiny)
│  │  │  │  │  ├────127.32 MB (02.52%) -- class(Call)/objects
│  │  │  │  │  │    ├──127.22 MB (02.51%) ── gc-heap
│  │  │  │  │  │    └────0.09 MB (00.00%) ── malloc-heap/slots
│  │  │  │  │  ├────108.11 MB (02.14%) -- class(Function)/objects
│  │  │  │  │  │    ├──107.12 MB (02.12%) ── gc-heap
│  │  │  │  │  │    └────0.99 MB (00.02%) ── malloc-heap/slots
│  │  │  │  │  └─────98.29 MB (01.94%) -- class(HTMLTableCellElement)/objects
│  │  │  │  │        ├──54.64 MB (01.08%) ── gc-heap
│  │  │  │  │        └──43.65 MB (00.86%) ── malloc-heap/slots
│  │  │  │  └──────2.85 MB (00.06%) ++ (7 tiny)
│  │  │  └─────12.78 MB (00.25%) ++ (3 tiny)
│  │  └─────50.87 MB (01.01%) ++ js-zone(0x29100964000)
│  └─────35.82 MB (00.71%) ++ (4 tiny)
├────672.73 MB (13.30%) ── heap-unclassified

and:

├────264.72 MB (05.23%) -- xpconnect
│    ├──264.47 MB (05.23%) ── runtime

both of which seem a little unusual.  Is the S3 interface just holding on to the blob objects (or whatever it created) that it uploaded?

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Some testcase here would be really nice. The link in the comment 0 doesn't work.

Comment 3

[Andrew McCreight [:mccr8]]

This is mostly orphan nodes, which means the webpage is holding alive DOM nodes that aren't part of the current document.

Comment 4

[Tyson Smith [:tsmith]]

(In reply to Olli Pettay [:smaug] from comment #2)
> Some testcase here would be really nice. The link in the comment 0 doesn't work.

Nah that wasn't meant to be a link. You'd need access to S3 account and buckets. I am willing to test/collect more logs if needed.

Comment 5

[Tyson Smith [:tsmith]]

Closing the tab and calling GC and CC in about:memory does reduce memory usage back down to a reasonable amount (~1.5GB)

Comment 6

[Kris Maglione [:kmag]]

There's also about 500MB of plain JS objects in that window, and about 700MB of heap-unclassified, which is a bit worrying. But I think it's pretty clear that this is a page script leak.

If you can get the developer tools memory panel to work on this page without OOMing, the dominator tree might tell us something more useful.

Comment 7

[Eric Rahm [:erahm]]

Closing for now, feel free to reopen if you can repro with more info.