834256 - Firefox crashes OOM while viewing PDF when many PDF documents are opened

Status: RESOLVED WONTFIX

(Firefox :: PDF Viewer, defect, P3)

Description

[Mihaela Velimiroviciu (:mihaelav)]

Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0 beta 3
Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20130124 Firefox/21.0, build id: 20130124054158

Steps to reproduce:
1. Open many PDFs in tabs
2. Focus on one of the PDFs
3. Scroll 2-3 pages in the document
4. Repeat steps 2&3 a few times

Expected result:
All PDFs load correctly. No crash occur.

Actual result:
Only a few pages of the documents are loaded (the rest are black or blank). Firefox crashes.

Crash report:
https://crash-stats.mozilla.com/report/index/bp-bbe31de1-6e34-4633-b8b6-3ea362130124

Note:
The crash didn't reproduce on Ubuntu 12.10 and Mac OS X 10.8.2 (on these platforms, some documents were not loaded at all, only the pdf viewer container is loaded, without any content)

Comment 1

[juan becerra [:juanb]]

Is this behavior different from previous, recent betas?

Comment 2

[Mihaela Velimiroviciu (:mihaelav)]

It crashes on 18.0(beta5), as well.

Comment 3

[Scoobidiver (away)]

We need a stack trace (see https://developer.mozilla.org/docs/How_to_get_a_stacktrace_with_WinDbg).

Comment 4

[Mihaela Velimiroviciu (:mihaelav)]

Attachment: debug logs

Comment 5

[Scoobidiver (away)]

It's bug 829954 with STR.

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

Assigning to Karl as well and will let him dupe bug 829954 to this one if they are indeed covering the same ground.

Comment 7

[Karl Tomlinson (:karlt)]

Are you able to link to any particular PDFs that cause the problem?
For example, is there one PDF that will demonstrate the problem when opened in many tabs concurrently?

Comment 8

[Karl Tomlinson (:karlt)]

Some things to think about:

There are mBlurRadius.width/height > 0 checks in the large surface path but no
such check before calling ComputeLobes and using those values in the
allocation size calculation.  I wonder whether either could be negative.

Some comments nearby say "No need to use CheckedInt here - we have validated
it in the constructor" but the CheckedInt size code in one of the constructors
does not look sufficient to ensure that integralImageSize.width *
integralImageSize.height does not overflow.

Is there any limit to the mBlurRadius size?

Comment 9

[Simona Badau, Desktop QA]

(In reply to Karl Tomlinson (:karlt) from comment #7)
> Are you able to link to any particular PDFs that cause the problem?
> For example, is there one PDF that will demonstrate the problem when opened
> in many tabs concurrently?

Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20130130 Firefox/21.0
Build ID: 20130130030907

http://www.ielts.org/pdf/information_for_candidates_booklet.pdf
This PDF crashes Firefox if is loaded in many tabs:
- on a Windows 7 32-bit machine (NVIDIA GeForce 210, Intel(R) Core(TM)2 Duo CPU E7500 @2.93GHz x 2) - Firefox crashes with 6 tabs loaded (I followed the steps from the Description).
- on a Windows 7 64-bit machine (NVIDIA GeForce GT 610, Intel(R) Core(TM) i5-3470 CPU @ 3.20 GHz 3.50 GHz) - Firefox crashes with 14 tabs loaded.

Other PDFs examples:
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/publications/JST2007-5.pdf
http://www.jsce.or.jp/committee/amc/jam/DOC/jam_makepdf.pdf
http://www.cyflex.jp/knowhow/f_know/f_mojibake.pdf
www.jasst.jp/archives/jasst07k/pdf/T1.pdf
http://www.usability.gov/pdfs/chapter18.pdf

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

FWIW, with the latest 19beta, I don't crash, but I do get the "this document couldn't be displayed correctly".

Comment 11

[Bas Schouten (:bas.schouten)]

Loading a large amounts of the above mentioned PDFs in a debug build of mozilla-inbound (running with Azure Content) I can certainly get things to go bad and eventually get a crash. But looking at about:memory this is just all the worker compartments/gc's taking up a lot of memory.

The allocation of a blur surface as in bug 829954 may then be the place where the crash takes place, however, that is most likely simply because we're most likely to -actually- run out of address space on allocation of a large, contiguous block of memory, which this allocation will be.

All in all from what I've seen so far I'd say this is not so much a graphics problem, but rather a problem in the memory usage of our PDF.js workers.

Comment 12

[Alex Keybl [:akeybl]]

(In reply to Bas Schouten (:bas.schouten) from comment #11)
> All in all from what I've seen so far I'd say this is not so much a graphics
> problem, but rather a problem in the memory usage of our PDF.js workers.

Sounds like this is going to be a wontfix for FF19, especially if the fix involves architectural changes to pdf.js. I don't think this behavior will block the feature's release though.

Sending over to the PDF viewer component.

Comment 13

[Yury Delendik (:yury)]

Alex, is there a reason you moved that from Core/Graphics? You can crash Firefox by opening multiple tabs (6-14) with with http://people.mozilla.com/~ydelendik/bug834256/web/viewer.html web page and wait. I think it's an HTML/Canvas rendering issue and not PDF Viewer.

Comment 14

[Milan Sreckovic [:milan] (needinfo for best results)]

My understanding is that we plain run out of memory.  It crashes in graphics because that is the place where large contiguous memory chunks are being allocated.  The actual solution is to use less memory in the first place - see Comment 11.  This may not be the case, but this is why it got moved to PDF viewer.

Comment 15

[Yury Delendik (:yury)]

Milan, you can look at http://people.mozilla.com/~ydelendik/bug834256/web/viewer.html as a regular page on the web. If this page could crash the browser, there is pretty good chance any web site can do that as well regardless of PDF Viewer improvements.

Comment 16

[Milan Sreckovic [:milan] (needinfo for best results)]

Not arguing this shouldn't be fixed; just saying that the triage suggests this is the actual out of memory issue, and that something should be done at the source of asking for it all.  On the other hand, Bug 829954 is also tracking the fact that we crash because of OOM.  There is overlap between these two bugs, but it seems this one is tracking all the memory usage, and the other one the fact that we crash.

Comment 17

[Wayne Mery (:wsmwk)]

is bug 842962 (which I reproduced) a duplicate?

Comment 18

[Lukas Blakk [:lsblakk] use ?needinfo]

This is either a dupe of bug 829954 (same crash signature) or it's a bug on improving the architecture of handling OOM errors but either way there's nothing to track here since we're tracking the crash in bug 829954.

Comment 19

[Rob North]

I'm not certain this is a simple OOM bug. Please read my bug report below, and see what you think. In particular the strange graphics memory results.

Observed with FF 20.0b2
I have encountered a similar bug with 4-6pdf files open in tabs.
Heavy random scrolling and switching between tabs seems to trigger this error.
I have had ~5 empty stack traces, and also this one:
https://crash-stats.mozilla.com/report/index/bp-f00cbcab-20c6-409c-825b-39b272130302
Time to crash while actively scrolling is probably over half a minute.

The pdf files involved were:
  http://www.lirmm.fr/~ducour/Publis/phtest.pdf
  http://haskell.cs.yale.edu/wp-content/uploads/2011/02/rt-frp.pdf
Which were each opened 2-3 times.
Also
  http://ompldr.org/vZjNrdw
Was useful (but not required) for triggering this.



Interestingly, I see bizarre memory stats in about:memory for graphics related memory:

A good result... 5tabs opened, and allowed to render one page:

 117.14 MB ── canvas-2d-pixel-bytes
  374.51 MB ── explicit
    0.10 MB ── gfx-d2d-surfacecache
  121.15 MB ── gfx-d2d-surfacevram
  251.47 MB ── gfx-d2d-vram-drawtarget
    0.34 MB ── gfx-d2d-vram-sourcesurface
    0.57 MB ── gfx-surface-image
    0.00 MB ── gfx-textures
          0 ── ghost-windows
  246.72 MB ── heap-allocated
  261.55 MB ── heap-committed
   14.79 MB ── heap-committed-unused
      5.99% ── heap-committed-unused-ratio
    2.29 MB ── heap-dirty
   58.24 MB ── heap-unused
    0.08 MB ── images-content-used-uncompressed
   57.00 MB ── js-gc-heap
          0 ── low-commit-space-events
  832.60 MB ── private
  629.67 MB ── resident
    4.39 MB ── storage-sqlite
1,595.50 MB ── vsize

Starting to go strange, update on scrolling is starting to slow down:

2,275.28 MB ── canvas-2d-pixel-bytes
   294.47 MB ── explicit
     0.02 MB ── gfx-d2d-surfacecache
-1,816.71 MB ── gfx-d2d-surfacevram [?!]
 4,662.99 MB ── gfx-d2d-vram-drawtarget
     0.50 MB ── gfx-d2d-vram-sourcesurface
     0.63 MB ── gfx-surface-image
     0.00 MB ── gfx-textures
           0 ── ghost-windows
   165.87 MB ── heap-allocated
   184.32 MB ── heap-committed
    18.40 MB ── heap-committed-unused
      11.09% ── heap-committed-unused-ratio
     3.66 MB ── heap-dirty
    37.09 MB ── heap-unused
     0.09 MB ── images-content-used-uncompressed
    62.00 MB ── js-gc-heap
           0 ── low-commit-space-events
   630.62 MB ── private
   549.98 MB ── resident
     3.40 MB ── storage-sqlite
 1,523.58 MB ── vsize


Just prior to crashing... oddly the -ve gfx-d2d-surfacevram has decreased!

3,899.47 MB ── canvas-2d-pixel-bytes
  547.46 MB ── explicit
    0.03 MB ── gfx-d2d-surfacecache
 -192.51 MB ── gfx-d2d-surfacevram [?!]
8,118.35 MB ── gfx-d2d-vram-drawtarget
    0.24 MB ── gfx-d2d-vram-sourcesurface
    0.36 MB ── gfx-surface-image
    0.00 MB ── gfx-textures
          0 ── ghost-windows
  334.30 MB ── heap-allocated
  358.84 MB ── heap-committed
   24.50 MB ── heap-committed-unused
      7.32% ── heap-committed-unused-ratio
    2.52 MB ── heap-dirty
   78.67 MB ── heap-unused
    0.06 MB ── images-content-used-uncompressed
   98.00 MB ── js-gc-heap
          0 ── low-commit-space-events
1,077.73 MB ── private
  936.06 MB ── resident
    5.07 MB ── storage-sqlite
2,181.31 MB ── vsize

All other memory stats (not attached) seem unremarkable!

And oddly, when I looked in the resource monitor for how much memory was consumed, seemed to be 1-2GB

Note this kind of crash made by day-to-day browsing impossible (I keep multiple tabs open, and switch between tabs). My solution was to disable the pdf.js viewer.

Comment 20

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.