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)

Is this behavior different from previous, recent betas?

It crashes on 18.0(beta5), as well.

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

It's bug 829954 with STR.

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

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?

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?

(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

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

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.

(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.

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.

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.

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.

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.

is bug 842962 (which I reproduced) a duplicate?

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.

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.

Closing because no crash reported since 12 weeks.