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

(NeedInfo from)



2 years ago
2 years ago


(Reporter: boxvpndem+bugzilla, Unassigned, NeedInfo)


(Depends on: 1 bug)

44 Branch
Windows 7

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [MemShrink:P2][dom-triaged][btpp-triage-followup-2016-02-23], URL)


(4 attachments)



2 years ago
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.


2 years ago
OS: Unspecified → Windows 7
Hardware: Unspecified → x86
Group: firefox-core-security
Whiteboard: [MemShrink]
Created attachment 8719886 [details]


2 years ago
Ever confirmed: true
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.
Component: Untriaged → DOM
Product: Firefox → Core
Created attachment 8719898 [details]
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%)
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.
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.
Created attachment 8719923 [details]
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.
Flags: needinfo?(seth)
Ah, no, I take back that statement about peak memory usage; apparently Task Manager is lying.
Whiteboard: [MemShrink] → [MemShrink][dom-triaged][triage-follow-up-2016-03-14]
Whiteboard: [MemShrink][dom-triaged][triage-follow-up-2016-03-14] → [MemShrink][dom-triaged][triage-follow-up-2016-02-23]
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.
Created attachment 8719942 [details]
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.
Depends on: 1248745
(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.
Bug 803709 covers some data URI inefficiencies which might be the source of a lot of our trouble here, BTW.
Whiteboard: [MemShrink][dom-triaged][triage-follow-up-2016-02-23] → [MemShrink][dom-triaged][btpp-triage-followup-2016-02-23]
Whiteboard: [MemShrink][dom-triaged][btpp-triage-followup-2016-02-23] → [MemShrink:P2][dom-triaged][btpp-triage-followup-2016-02-23]
You need to log in before you can comment on or make changes to this bug.