1954106 - Opening of a small pdf file caused massive memory usage

Status: NEW

(Firefox :: PDF Viewer, defect, P3)

Description

[Silvio Vescovo]

Attachment: OpenMP-4.5-1115-CPP-web.pdf

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:136.0) Gecko/20100101 Firefox/136.0

Steps to reproduce:

I opened a pdf file with firefox

Actual results:

The loading time of the 8 pages of the pdf took a few seconds and eventually firefox crashed because my system was out of ram.

Expected results:

Open the pdf file without crashing.

Comment 1

[Calixte Denizet (:calixte)]

:Silvio, could you open about:crashes and share the link of the crash report ?
Anyway I opened the pdf at 220% and the second page took a lot of time to render:
https://share.firefox.dev/4i6N3QU

We spend a lot of time in creating a pattern before stroking:
https://github.com/mozilla/pdf.js/blob/9967ab4aa821fb18fcdd8fd6e47794a957c3aa3a/src/display/canvas.js#L2195
The pattern is a gradient we create here:
https://github.com/mozilla/pdf.js/blob/9967ab4aa821fb18fcdd8fd6e47794a957c3aa3a/src/display/pattern_helper.js#L90

I don't know if the crash is due to the pattern creation but for sure there is something to do in this area.
:lsalzman, is there something we can do better on the pdf.js' side ? or is it a known canvas issue ?

Comment 2

[Silvio Vescovo]

(In reply to Calixte Denizet (:calixte) from comment #1)

:Silvio, could you open about:crashes and share the link of the crash report ?
Anyway I opened the pdf at 220% and the second page took a lot of time to render:
https://share.firefox.dev/4i6N3QU

We spend a lot of time in creating a pattern before stroking:
https://github.com/mozilla/pdf.js/blob/9967ab4aa821fb18fcdd8fd6e47794a957c3aa3a/src/display/canvas.js#L2195
The pattern is a gradient we create here:
https://github.com/mozilla/pdf.js/blob/9967ab4aa821fb18fcdd8fd6e47794a957c3aa3a/src/display/pattern_helper.js#L90

I don't know if the crash is due to the pattern creation but for sure there is something to do in this area.
:lsalzman, is there something we can do better on the pdf.js' side ? or is it a known canvas issue ?

Hello, sadly I don't have any crash report because the firefox process is killed by the OOM Killer. I just tried to lower as much as possible the likeliness of the OOM Killing the firefox process, but either an other process is killed or the firefox one is eventually killed.
Even when artificially loading the system memory, I don't get a crash report.

Comment 3

[Lee Salzman [:lsalzman]]

Silvio, can you check about:config and let us know the value of your "pdfjs.enableHWA" pref?

Comment 4

[Lee Salzman [:lsalzman]]

Calixte, what I can gather from the profile is that clearRect gets called (I am guessing inside getPattern), and this causes any copy-on-write snapshots of that particular canvas to then get copied, causing the performance impact.

Now, why are there so many snapshots lying around to be copied in the first place? If the snapshots were transient and went away before clearRect was called, we wouldn't expect that to occur, since we would detect there were no outstanding snapshots to copy. But somehow, some way, these snapshots from previous uses of the canvas are still around at the time clearRect comes around, causing the performance issue, and the memory issue I would wager?

Comment 5

[Silvio Vescovo]

(In reply to Lee Salzman [:lsalzman] from comment #3)

Silvio, can you check about:config and let us know the value of your "pdfjs.enableHWA" pref?

Hello, my value of "pdfjs.enableHWA" is false.

Comment 6

[Mayank Bansal]

can repro with pdfjs.enableHWA=False on my Win11x64 AMD iGPU machine.

Comment 7

[Mayank Bansal]

Attachment: about:support

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:calixte, could you have a look please?

For more information, please visit BugBot documentation.

Comment 9

[Calixte Denizet (:calixte)]

Unfortunately, removing the clearRect doesn't change anything.
It seems that we create almost always the same pattern with the same gradient so we can probably cache it.
That said, while reading the code, I'm not sure we really need to have a pattern here.