931468 - excessive memory usage by internal pdf reader (~100MB/page)

Status: RESOLVED DUPLICATE of bug 959925

(Firefox :: PDF Viewer, defect)

Description

[Marcin Ślusarz]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130911155223

Steps to reproduce:

Open this PDF in Firefox 24:
http://ridl.cfd.rit.edu/products/manuals/Agilent/signal%20analyzer/Supplemental.pdf



Actual results:

As I scroll through this document ~100MB are taken by every non-blank page.

Comment 1

[Brendan Dahl [:bdahl]]

Seems this has been fixed in later versions can you try the nightly version of firefox?

Comment 2

[Marcin Ślusarz]

Not really. It seems garbage collection is more aggressive, but it still eats 100MB/page on this document and I can easily reproduce 1.5GB memory usage (above startup consumption) just by scrolling ~10 pages.

(It's easier to reproduce it when file is opened from disk)

Comment 3

[Marcin Ślusarz]

(in case it wasn't clear - I tested nightly version)

Comment 4

[Petruta Horea [:phorea], Desktop QA]

Reproduced using latest Aurora - 20131118004001 (seen up to 1.7GB memory usage).
Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0

Comment 5

[David Filiatrault]

Reproduced Firefox 26 on Ubuntu 13.10 (with updates as of 12/17/2013) running within VirtualBox using http://pbadupws.nrc.gov/docs/ML0909/ML090920467.pdf where clicking page down button to page 149 results in Webconsole reporting that pdf.js:106 "Warning: Unhandled rejection: out of memory"

Comment 6

[David Filiatrault]

The PDF in Comment #5, http://pbadupws.nrc.gov/docs/ML0909/ML090920467.pdf is a scanned image PDF. This same PDF using the same click page down repeatedly can reproduced a crash in Iceweasel 24ESR running in Tail 0.22 running in a VM with 2048 of RAM.

Also, this same PDF,  when hitting page down in rapid succession (less than 1s between pauses) using Firefox Nightly 2013-12-17 on OSX 10.9 consumed up to 2.6GB of memory.  After 60 seconds without any clicks, memory usage dropped to 756.3MB.  No crash occurred, likely due to not running out of memory due to 8GB of physical ram on this MacBookPro

Comment 7

[Nicholas Nethercote [inactive]]

For this document, lots of memory is allocated in PDFImage_getImageData.  Specifically:

- It creates a RGBA buffer of size h*w*4.

- It then calls fillRgbaBuffer, which creates a RGB buffer of size h*w*3, fills it in, then copies the RGB data into the RGBA buffer.

- Similarly, an opacity (A) buffer of size h*w is created and then copied into the RGBA buffer.

If the RGB and A data were instead put directly into the RGBA buffer, we'd halve the memory consumption of this step. Unfortunately, there are some complications because sometimes the RGB and A data is a different size and we have to scale it. Still, it might be possible, and is worth thinking about.

Comment 8

[Nicholas Nethercote [inactive]]

The PDFs mentioned in comment 0 and comment 5 are both scanned PDFs. Bug 959925 has identified the issues relating to scanned PDFs, and the work will be done there.