Page with a single <pre> block containing 7.4 MB of text containing unescaped '<' and '>' consumes 1,762 MB of nsInlineFrame memory

RESOLVED INACTIVE

Status

()

Core
General
RESOLVED INACTIVE
5 years ago
2 days ago

People

(Reporter: njn, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P3], URL)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
The page is simply this:

  <html><pre>
  ... 7.4 MiB of text ...
  </pre></html>

Here's the relevant part of about:memory:

1,919.57 MB (100.0%) -- explicit
├──1,833.55 MB (95.52%) -- window-objects
│  ├──1,803.68 MB (93.96%) -- top(http://people.mozilla.org/~bhackett/gcFunctions.html, id=22)
│  │  ├──1,795.22 MB (93.52%) -- active/window(http://people.mozilla.org/~bhackett/gcFunctions.html)
│  │  │  ├──1,787.93 MB (93.14%) -- layout
│  │  │  │  ├──1,771.20 MB (92.27%) -- frames
│  │  │  │  │  ├──1,762.14 MB (91.80%) ── nsInlineFrame
│  │  │  │  │  └──────9.06 MB (00.47%) ++ (3 tiny)
│  │  │  │  └─────16.73 MB (00.87%) ++ (7 tiny)
│  │  │  └──────7.29 MB (00.38%) ++ (3 tiny)
│  │  └──────8.46 MB (00.44%) ++ cached/window(https://www.google.com.au/)

Opening the page makes Firefox unusable for 30 seconds or more.

This is *ridiculous*.  7.4 MB to 1762 MB is a 238x increase!

It's also similar to bug 216418, though this page may be simpler.
(Reporter)

Comment 1

5 years ago
Created attachment 710380 [details]
gzip'd test page

Here's a gzip'd copy of the page.
(Reporter)

Updated

5 years ago
OS: Windows 2000 → All
Hardware: x86 → All
(Reporter)

Comment 2

5 years ago
FWIW, if I remove the tags and rename it as gcFunctions.txt things are *much* better:

124.37 MB (100.0%) -- explicit
├───62.38 MB (50.16%) -- window-objects
│   ├──51.24 MB (41.20%) -- top(file:///home/njn/gcFunctions.txt, id=8)
│   │  ├──50.18 MB (40.35%) -- active/window(file:///home/njn/gcFunctions.txt)
│   │  │  ├──42.76 MB (34.38%) -- layout
│   │  │  │  ├──28.48 MB (22.90%) ── text-runs
│   │  │  │  ├───9.08 MB (07.30%) -- frames
│   │  │  │  │   ├──9.08 MB (07.30%) ── nsContinuingTextFrame
│   │  │  │  │   └──0.00 MB (00.00%) ── sundries
│   │  │  │  ├───4.84 MB (03.89%) ── line-boxes
│   │  │  │  └───0.36 MB (00.29%) ++ (5 tiny)
│   │  │  ├───7.13 MB (05.73%) -- dom
│   │  │  │   ├──7.12 MB (05.73%) ── text-nodes
│   │  │  │   └──0.01 MB (00.01%) ++ (3 tiny)
│   │  │  └───0.29 MB (00.23%) ++ (3 tiny)
GC Function: JSObject* js::GlobalObject::getOrCreateObject(JSContext*, uint32, (uint8)(JSContext*,class JS::Handle<js::GlobalObject*>)*)

<js::GlobalObject*> gets interpreted as an html tag, it's never closed, it creates an inline box, so we get a highly nested structure.
> The page is simply this:

Uh, no it's not.  If it were there would not be a single nsInlineFrame on the page.

What the page _is_ is this:

<html><pre>some text ... <js::GlobalObject*>...<JSObject*>....etc, etc</pre></html>

Each of those unknown tags caused by not escaping '<' and '>' creates an element, which gets an inline frame per line that element spans (because these elements are unknown, and CSS defaults things to inline display).  Since none of those elements are ever closed, they span a lot of lines.  For example, that first tag appears on line 136 and the page has 79319 lines, so that's 79183 inline frames for just that element.  There are 32475 elements on this page, not counting the <pre> and <html>.

And yes, this similar to bug 216418: incredibly deep inline tag nesting with each tag spanning many thousands of lines.  This one just has even more inline elements.  Pretty sure we have other bugs covering this edge case too.
Summary: Page with a single <pre> block containing 7.4 MB of text consumes 1,762 MB of nsInlineFrame memory → Page with a single <pre> block containing 7.4 MB of text containing unescaped '<' and '>' consumes 1,762 MB of nsInlineFrame memory
(Reporter)

Comment 5

5 years ago
Ok!  Much less important, then.  Thanks, bz.
(Reporter)

Updated

5 years ago
Whiteboard: [MemShrink] → [MemShrink:P3]

Comment 6

2 days ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 2 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.