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)
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.
Reporter | ||
Updated•8 years ago
|
Updated•8 years ago
|
Group: firefox-core-security
Whiteboard: [MemShrink]
Comment 1•8 years ago
|
||
Updated•8 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•8 years ago
|
||
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
Comment 3•8 years ago
|
||
Comment 4•8 years ago
|
||
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•8 years ago
|
||
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•8 years ago
|
||
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•8 years ago
|
||
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)
Comment 8•8 years ago
|
||
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]
Comment 9•8 years ago
|
||
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•8 years ago
|
||
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•8 years ago
|
||
(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•8 years ago
|
||
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]
Updated•8 years ago
|
Whiteboard: [MemShrink][dom-triaged][btpp-triage-followup-2016-02-23] → [MemShrink:P2][dom-triaged][btpp-triage-followup-2016-02-23]
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Comment 13•5 years ago
|
||
Can you reproduce this on the current version?
Flags: needinfo?(boxvpndem+bugzilla)
Comment 14•5 years ago
|
||
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)
Updated•5 years ago
|
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
Comment 15•5 years ago
|
||
Updated•6 months ago
|
Flags: needinfo?(boxvpndem+bugzilla)
You need to log in
before you can comment on or make changes to this bug.
Description
•