Closed Bug 1248261 Opened 8 years ago Closed 5 years ago

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

Categories

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

44 Branch
x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: boxvpndem+bugzilla, Unassigned)

References

(Depends on 1 open bug, )

Details

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

Attachments

(5 files)

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.
OS: Unspecified → Windows 7
Hardware: Unspecified → x86
Group: firefox-core-security
Whiteboard: [MemShrink]
Attached file call_stack.txt
Status: UNCONFIRMED → NEW
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
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.
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.
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]
Component: DOM → DOM: Core & HTML

Can you reproduce this on the current version?

Flags: needinfo?(boxvpndem+bugzilla)

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.]

Flags: needinfo?(seth.bugzilla)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
Flags: needinfo?(boxvpndem+bugzilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: