879320 - Memory usage while reading big PDFs gradually increases until browser OOMs

Status: RESOLVED WORKSFORME

(Firefox :: PDF Viewer, defect, P4)

Description

[Gian-Carlo Pascutto [:gcp]]

STR:

1) Load a big book, e.g. http://stacks.math.columbia.edu/download/book.pdf
2) Start scrolling, giving some minimal time to let individual pages load.
3) Watch memory usage.
4) See browser go boom as Firefox exceeds 2Gb RAM usage.

Looks like decoded/rendered pages are cached but never freed.

Comment 1

[Loic]

Maybe Firefox should discard PDF pages which are not displayed, like it does for images (if that's not the case).

Comment 2

[Nicholas Nethercote [inactive]]

An about:memory measurement would be very helpful.  If you're on Nightly, please "Measure and save" and attach the resulting .json.gz file.  Thanks!

Comment 3

[Gian-Carlo Pascutto [:gcp]]

Attachment: about:memory report

Comment 4

[(mostly gone) XtC4UaLL [:xtc4uall]]

This is WFM using Firefox 2 and newer. Getting ~700/750 MB Ram Usage on Scrolling through the first 20 Pages.

Comment 5

[Gian-Carlo Pascutto [:gcp]]

Still trivially reproduces on currently Nightly.

>Getting ~700/750 MB Ram Usage on Scrolling through the first 20 Pages.

Uh, the document has 3800+ pages. Try reading more than 1% of it.

Comment 6

[Nicholas Nethercote [inactive]]

gcp, how does Nightly do now? Memory usage seems ok to me now, considering the document size -- I couldn't get Firefox's RSS above ~800 MiB -- but maybe I'm not interacting with the document in the same way you are.

Comment 7

[Gian-Carlo Pascutto [:gcp]]

Attachment: memory-report.json.gz

Comment 8

[Gian-Carlo Pascutto [:gcp]]

I can still get it arbitrarily high by browsing through the document. It seems to raise less sharply (i.e. pdf.js memory usage is better), but still keeps going up (i.e. it's still *leaking*).

I attached a memory report where it's using about 2.3G.

Comment 9

[Nicholas Nethercote [inactive]]

This is interesting:

> │    ├──719.08 MB (41.94%) -- top(http://stacks.math.columbia.edu/download/book.pdf, id=121)
> │    │  ├──653.60 MB (38.12%) -- active/window(http://stacks.math.columbia.edu/download/book.pdf)
> │    │  │  ├──402.67 MB (23.48%) -- dom
> │    │  │  │  ├──390.55 MB (22.78%) ── orphan-nodes
> │    │  │  │  └───12.12 MB (00.71%) ++ (5 tiny)

As is this:

> 4,372.27 MB ── gpu-committed
> 1,580.04 MB ── gpu-dedicated
>    20.52 MB ── gpu-shared

Comment 10

[Nicholas Nethercote [inactive]]

gcp: another interesting experiment would be to append "#textLayer=off" to the URL through which you access the file. This disables the text layer, which means you won't be able to select text, but it might make pdf.js faster and use less memory. I think it will also prevent orphan nodes from accumulating, since the text layer is the only part of pdf.js (AFAIK) that involves lots of DOM nodes.

Comment 11

[Gian-Carlo Pascutto [:gcp]]

Attachment: memory-report.json.gz with #textLayer=off

Comment 12

[Gian-Carlo Pascutto [:gcp]]

Sounds like you found it indeed. Memory usage increases by about 300M when the PDF is opened, but increases negligibly after that and barely went over 900M even after reading halfway through it.

Comment 13

[Nicholas Nethercote [inactive]]

Bug 1054161 may help substantially.

Comment 14

[Marco Castelluccio [:marco]]

Memory usage is not that high anymore, please reopen if you can still reproduce.