STR: 1. Load http://www.samba.org/samba/docs/Samba3-ByExample.pdf (which is quite big). 2. Select the title text "Samba-3 by Example" on the first page. 3. Attempt to print the selection (click Print toolbar button, choose "Selection"). 4. Get this crash: xul.dll!gfxPlatform::CreateDrawTargetForSurface(gfxASurface * aSurface, const mozilla::gfx::IntSize & aSize) Line 513 + 0xc bytes xul.dll!nsSimplePageSequenceFrame::PrePrintNextPage(nsITimerCallback * aCallback, bool * aDone) Line 646 xul.dll!nsPrintEngine::PrePrintPage() Line 2740 + 0x3d bytes xul.dll!nsPagePrintTimer::Notify(nsITimer * timer) Line 137 + 0xb bytes xul.dll!nsTimerImpl::Fire() Line 486 xul.dll!nsTimerEvent::Run() Line 567 xul.dll!nsThread::ProcessNextEvent(bool mayWait, bool * result) Line 627 + 0x19 bytes In nsSimplePageSequenceFrame::PrePrintNextPage, the renderingSurface->CreateSimilarSurface() call returns null. Inside there, ::CreateDIBSection is being called and it fails to create a bitmap; GetLastError() == 8, which is "Not enough storage space is available to process this command.". I suspect we're running out of GDI handles. For this PDF, mCurrentCanvasList has length 638 (it's one per page of the PDF I guess?). I think first we should at least check printSurface and continue in the loop if it is null. Second, can we avoid creating the surfaces and dispatching these tasks all at once, and instead do a page at a time, maybe when we come back in to PrePrintNextPage?

It's reproducible. It's only #79 browser crasher in 19.0b1 but I'm asking for tracking in 19.0 because it's the first version where PDF Viewer will land. More reports at: https://crash-stats.mozilla.com/report/list?signature=gfxPlatform%3A%3ACreateDrawTargetForSurface%28gfxASurface*%2C+mozilla%3A%3Agfx%3A%3AIntSize+const%26%29

Let's deal with the crash here and I'll clone the bug for handling many pages better.

I assume your build has the fix for bug 717178 in it? That bug was eating GDI resources like crazy for large print jobs.

Yes I was working off tip.

The patch avoids the crash but now results in an OOM error with the PDF I used. Don't know if that's much better (although there probably are some sizes of PDFs that would print successfully with this patch than without). Hopefully bug 830278 helps out more with the size problems.

Tracking to ensure we get this in the first version shipping PDF viewer.

Comment on attachment 701733 [details] [diff] [review] patch [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 745025 User impact if declined: Printing large PDFs in pdf.js will crash. Testing completed (on m-c, etc.): Fix has been on m-c for a week; local testing sees this crash is now avoided. Risk to taking this patch (and alternatives if risky): Very low String or UUID changes made by this patch: N/A

https://hg.mozilla.org/releases/mozilla-aurora/rev/6498d9b7108e https://hg.mozilla.org/releases/mozilla-beta/rev/84de5f4f1773

Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0 Build ID: 20130123083802 Firefox 19 beta 3 still crashes when using the STR from the Description. https://crash-stats.mozilla.com/report/index/bp-7740721d-9fce-48a8-8a39-931cf2130124 The crash is intermittent, and when Firefox does not crash a Print Preview Error is got (An unknown error occurred while printing). After the error, the page where the pdf was loaded is blank and the pdf can't be loaded in any other tabs or windows. Different pdfs are loaded but there is no content in the PDF viewer.

Here is a crash ID on m-c (still in the queue): bp-66c89a05-7006-476e-9920-dff422130124.

That matches up with my comment 6. I believe the crash due to Windows running out of handles is fixed by the patch here, but the more general problem of not being able to print PDFs with many pages continues to exist. I filed bug 830278 to handle that, although I think now that my suggestion in that bug is not going to help.

(In reply to Scoobidiver from comment #13) > Here is a crash ID on m-c (still in the queue): > bp-66c89a05-7006-476e-9920-dff422130124. Was this following the steps in comment 0 (i.e., printing a selection)? Bug 830278 morphed into disabling selection printing in pdf.js altogether, so with that now landed it should not be possible to trigger this crash and I think we can close this bug.

(In reply to Cameron McCormack (:heycam) from comment #15) > Was this following the steps in comment 0 (i.e., printing a selection)? Yes. Printing a selection still crashes but with an empty signature that it will be handled in bug 830278.

Firefox 19 beta 5 still crashes when using the STR from the Description. Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0 Build ID: 20130206083616 When Firefox does not crash I get the same printing error as described in Comment 12. This time the signatures are not empty: https://crash-stats.mozilla.com/report/index/bb4f17b9-0685-43dc-acac-a6eac2130207

Scoobidiver, do you think comment 17 is the same crash or should we file a follow-up bug on this?

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #18) > Scoobidiver, do you think comment 17 is the same crash or should we file a > follow-up bug on this? I can't reproduce any crash in 19.0b6 because selection printing is disabled.

(In reply to Scoobidiver from comment #19) > I can't reproduce any crash in 19.0b6 because selection printing is disabled. Ah yes, you are right. I'm going to call this verified because the crashes no longer reproduce with the caveat that we'll want to do extensive regression testing if/when we re-enable PDF text selection.