1248261 - High memory usage and Firefox crash on previewing attached URI on box.com

Status: RESOLVED WORKSFORME

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

Description

[boxvpndem+bugzilla]

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36

Steps to reproduce:

1) Navigate to: https://app.box.com/s/hxbl2lg0t5wyyz4ukk9sqzyai0uztch7
2) Wait for about 1 minute, Firefox crashes after too much memory usage.
3) PCs have 2GB RAM.
4) Firefox 44.0.2
5) Windows 7 and Windows 10
6) 3 different machines reproduce the same behavior



Actual results:

I see high memory usage up to 1.9GB total on Windows performance monitor, and  crashes.


Expected results:

Firefox is expected not to crash.

Comment 1

[Tyson Smith [:tsmith]]

Attachment: call_stack.txt

Comment 2

[Andrew McCreight [:mccr8]]

Based on the stack, it looks like this is crashing inside Window::btoa, so it is either a DOM issue or some kind of string issue.

Comment 3

[Andrew McCreight [:mccr8]]

Attachment: box-memory-report.json.gz

Comment 4

[Andrew McCreight [:mccr8]]

Two things of note in the memory report:
- A bunch of 8mb JS strings, totaling about 300mb, that look like this:
  string(length=2147558, copies=1, "<svg class="crocodoc-V0PXdf crocodoc-page-svg" version="1.1"/n    xmlns="http://www.w3.org/2000/sv
- High heap-unclassified (345mb, 42%)

Comment 5

[Andrew McCreight [:mccr8]]

If you leave it open longer, the JS strings seem to mostly go away, but heap-unclassified keeps climbing:

2,046.44 MB (100.0%) -- explicit
├──1,484.78 MB (72.55%) ── heap-unclassified
├────384.79 MB (18.80%) -- window-objects/top(https://app.box.com/s/hxbl2lg0t5wyyz4ukk9sqzyai0uztch7, id=2147483649)

Presumably the heap-unclassified is coming from XPCOM string stacks like Tyson posted.

Comment 6

[Andrew McCreight [:mccr8]]

Memory usage seems to stay around 350mb in Chrome, but it keeps climbing up and up past 1gb in Firefox, within the course of like a minute.

Comment 7

[Nathan Froyd [:froydnj]]

Attachment: dmd report from win64 post-page load

Peak memory usage here is much worse than normal memory usage; I was able to successfully load the site with a 64-bit Firefox, with a max memory usage according to Task Manager of ~2.5GB.  But 15 minutes later, the site is down to a much more respectable ~420MB or so.

I've attached the DMD report for shortly after the site was loaded.  Highlights:

* ~350MB of CSS errors.  It's not that there are a lot of CSS errors, but that we're keeping around the "line" of the stylesheet they came from, which can be a rather massive line with minified CSS.

* ~530MB of raw string URLs inside ImageURL structures.  These are actually coming from *two* separate places inside the image loader, and the memory is evenly divided between the two spots.

- We are constructing ImageURLs inside imgRequest::Init.
- We are also constructing ImageURLs for an ImageCacheKey in imgLoader::LoadImage.

This seems like a waste, but perhaps there's no good way around this.

* ~260MB of text in CSSParserImpl::mToken, if I'm reading the stack and the code correctly.  I guess this is tied up in SVG images somehow?

* ~180MB tied up in the string members of URLs that eventually wind up getting passed into the image loader, so I think imgRequest or ImageURL must be holding onto the URLs.

* ~120MB tied up in the string members of URLs that are related to fonts.  I'm guessing these are for error reporting somehow?  Or data: URLs?

Those are the highlights; everything after that is kind of uninteresting, and probably related to some of those things being so large.

ni? to Seth for his expert opinion on some of the imglib-related stuff above.

Comment 8

[Nathan Froyd [:froydnj]]

Ah, no, I take back that statement about peak memory usage; apparently Task Manager is lying.

Comment 9

[Daniel Holbert [:dholbert]]

FWIW, the page has a *ton* of data URIs, for SVG images and fonts. (And data URI encoded fonts inside of data URI encoded SVG images.)

 (1) I count 20 distinct font-face "data:font/ttf;" data URIs in the document, at least one of which is 984KB in size. (about a meg)

 (2) I count 30 distinct <img src="data:image/svg+xml....."> elements, and the first two at least seem to be 2-3MB in size.

 (3) Inside of a given SVG file from (2), I see more huge font-face styles, with data-URI-encoded font files.

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: sample SVG file, which is encoded as a data URI inside the page

Here's one sample SVG file that's encoded as a data URI in this page, for the record. 93% of its size is data-URI-encoded fonts, and most of the rest is a single <image> element with a data-URI-encoded JPEG image.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Nathan Froyd [:froydnj] from comment #7)
> * ~350MB of CSS errors.  It's not that there are a lot of CSS errors, but
> that we're keeping around the "line" of the stylesheet they came from, which
> can be a rather massive line with minified CSS.

(Looks like mccr8 spun this part off as bug 1248745.)

As for the font/CSS-related data URIs: these are presumably from the data URIs (and the duplicate font data URIs which seem to be reencoded inside of each data-URI-encoded SVG document here).

I wonder if we should maintain some sort of "recently used data URI" cache, to facilitate string buffer sharing among data URIs...  I have no idea how hard that would be, but it seems like that would buy us back the majority of this memory.

Comment 12

[Daniel Holbert [:dholbert]]

Bug 803709 covers some data URI inefficiencies which might be the source of a lot of our trouble here, BTW.

Comment 13

[Patricia Lawless]

Can you reproduce this on the current version?

Comment 14

[Daniel Holbert [:dholbert]]

I think the page has changed significantly, via a Box redesign at some point.

Following up on the issues with data URIs in comment 9: I don't actually get any hits for data: in the DOM today (using the "search HTML" bar at the top of the DevTools inspector pane). And it looks like the penguin image is displayed as a <canvas> these days.

Also, I don't see any CSS errors when loading the page today.

So I think this is WORKSFORME via changes to the page, though it'd be great to get confirmation of that from the reporter.

[Also: canceling a stale needinfo for seth, who's not active on bugzilla these days.]

Comment 15

[Daniel Holbert [:dholbert]]

Attachment: data URI encoding of previously-attached >2MB "sample SVG file"