crash in nsDeviceContextSpecX::EndPage @ decode_data when printing

VERIFIED FIXED in Firefox 24, Firefox OS v1.2

Status

()

--
critical
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: scoobidiver, Assigned: smichaud)

Tracking

({crash, regression, reproducible})

19 Branch
mozilla28
x86_64
Mac OS X
crash, regression, reproducible
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox21 wontfix, firefox22 wontfix, firefox23 wontfix, firefox24+ fixed, firefox25+ fixed, firefox26+ verified, firefox27 verified, firefox28 verified, b2g-v1.2 fixed)

Details

(Whiteboard: STR in comment #35; , crash signature, URL)

Attachments

(8 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
It's #35 browser crasher in 21.0 and #56 in 22.0b3 on Mac OS X.

All comments talk about printing.

Signature 	decode_data More Reports Search
UUID	1fbea823-32e7-4482-aaa1-f5b162130605
Date Processed	2013-06-05 23:30:27
Uptime	24880
Last Crash	more than 3 months before submission
Install Age	1.2 days since version was first installed.
Install Time	2013-06-04 19:23:34
Product	Firefox
Version	23.0a2
Build ID	20130604004018
Release Channel	aurora
OS	Mac OS X
OS Version	10.6.8 10K549
Build Architecture	amd64
Build Architecture Info	family 6 model 15 stepping 6
Crash Reason	EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address	0x7a300000
App Notes 	
AdapterVendorID: 0x1002, AdapterDeviceID: 0x7249
Processor Notes 	sp-processor05_phx1_mozilla_com_32331:2012; exploitability tool: ERROR: unable to analyze dump
EMCheckCompatibility	True
Adapter Vendor ID	0x1002
Adapter Device ID	0x7249

Frame 	Module 	Signature 	Source
0 	CoreGraphics 	decode_data 	
1 	CoreGraphics 	img_decode_read 	
2 	CoreGraphics 	img_alphamerge_read 	
3 	CoreGraphics 	CGSImageStreamRead 	
4 	libPDFRIP.A.dylib 	PDFImageEmitDefinition 	
5 	CoreFoundation 	__CFSetApplyFunction_block_invoke_1 	
6 	CoreFoundation 	CFBasicHashApply 	
7 	CoreFoundation 	CFSetApplyFunction 	
8 	libPDFRIP.A.dylib 	PDFImageSetEmitDefinitions 	
9 	libPDFRIP.A.dylib 	emit_page_resources 	
10 	libPDFRIP.A.dylib 	PDFDocumentEndPage 	
11 	libPDFRIP.A.dylib 	pdf_EndPage 	
12 	PrintCore 	pdfSpoolingEndPage 	
13 	PrintCore 	PJCEndPage 	
14 	PrintCore 	PMSessionEndPageNoDialog 	
15 	XUL 	nsDeviceContextSpecX::EndPage 	widget/cocoa/nsDeviceContextSpecX.mm:116
16 	XUL 	nsDeviceContext::EndPage 	gfx/src/nsDeviceContext.cpp:562
17 	XUL 	_ZThn112_N25nsSimplePageSequenceFrame9DoPageEndEv 	layout/generic/nsSimplePageSequence.cpp:780
18 	XUL 	nsPrintEngine::PrintPage 	layout/printing/nsPrintEngine.cpp:2850
19 	XUL 	nsPagePrintTimer::Run 	layout/printing/nsPagePrintTimer.cpp:87
20 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:627
21 	CoreFoundation 	__CFSetApplyFunction_block_invoke_1 	
22 	CoreFoundation 	CFBasicHashApply 	
23 	XUL 	NS_ProcessPendingEvents 	obj-firefox/x86_64/xpcom/build/nsThreadUtils.cpp:188
24 	XUL 	nsBaseAppShell::NativeEventCallback 	widget/xpwidgets/nsBaseAppShell.cpp:97
25 	XUL 	nsAppShell::ProcessGeckoEvents 	widget/cocoa/nsAppShell.mm:387
26 	CoreFoundation 	CFSetApplyFunction 	
27 	CoreFoundation 	__CFRunLoopDoSources0 	
28 	CoreFoundation 	__CFRunLoopDoSources0 	
29 	CoreFoundation 	__CFRunLoopRun 	
30 	libmozglue.dylib 	ozone_size 	memory/mozjemalloc/jemalloc.c:7003
31 	XUL 	XUL@0x12cbe80 	
32 	CoreGraphics 	__FUNCTION__.96944 	
33 	CoreGraphics 	bindDisplayMapping 	
34 	XUL 	nsXULTooltipListener::HandleEvent 	obj-firefox/x86_64/dist/include/nsTSubstring.h:85
35 	CoreGraphics 	updateAllDisplayInfoAsNeeded 	
36 	AppKit 	-[NSView _convertPointToSuperview:] 	
37 	CoreGraphics 	CGSLockShmemLockWithTimeout 	
38 	CoreGraphics 	CGSLockShmemLockWithTimeout 	
39 	CoreGraphics 	__FUNCTION__.98043 	
40 	XUL 	nsIXULWindow::COMTypeInfo<int>::kIID 	
41 	XUL 	nsGenericHTMLElement::DOMQueryInterface 	content/html/content/src/nsGenericHTMLElement.cpp:269
42 	XUL 	nsIXULWindow::COMTypeInfo<int>::kIID 	
43 	CoreFoundation 	CFStringCompareWithOptionsAndLocale 	
44 	XUL 	nsCOMPtr_base::assign_from_qi 	obj-firefox/x86_64/xpcom/build/nsCOMPtr.cpp:14
45 	XUL 	nsEventStateManager::IsRemoteTarget 	obj-firefox/x86_64/dist/include/nsCOMPtr.h:596
46 	XUL 	nsEventStateManager::PostHandleEvent 	obj-firefox/x86_64/dist/include/nsAutoPtr.h:880
47 	XUL 	nsDOMUIEvent::DuplicatePrivateData 	content/events/src/nsDOMUIEvent.cpp:429
48 	libSystem.B.dylib 	pthread_mutex_lock 	
49 	libSystem.B.dylib 	pthread_mutex_unlock 	
50 	CarbonCore 	TSUnlockMutex 	

More reports at:
https://crash-stats.mozilla.com/report/list?signature=decode_data
(Reporter)

Comment 1

5 years ago
More reports also at:
https://crash-stats.mozilla.com/report/list?signature=CoreGraphics%400xa2900
https://crash-stats.mozilla.com/report/list?signature=CoreGraphics%400x7faf3
https://crash-stats.mozilla.com/report/list?signature=CoreGraphics%400x7fe6f
Crash Signature: [@ decode_data] → [@ decode_data] [@ CoreGraphics@0xa2900 ] [@ CoreGraphics@0x7faf3 ] [@ CoreGraphics@0x7fe6f ]
status-firefox24: --- → affected
Hardware: All → x86_64
(Reporter)

Updated

5 years ago
Crash Signature: [@ decode_data] [@ CoreGraphics@0xa2900 ] [@ CoreGraphics@0x7faf3 ] [@ CoreGraphics@0x7fe6f ] → [@ decode_data] [@ CoreGraphics@0xa2900 ] [@ CoreGraphics@0x7faf3 ] [@ CoreGraphics@0x7fe6f ] [@ CoreGraphics@0x77b2f ]
status-firefox25: --- → affected
(Reporter)

Comment 2

5 years ago
It's #10 browser crasher in 23.0 and #1 in 24.0b1 on Mac OS X.
Crash Signature: [@ decode_data] [@ CoreGraphics@0xa2900 ] [@ CoreGraphics@0x7faf3 ] [@ CoreGraphics@0x7fe6f ] [@ CoreGraphics@0x77b2f ] → [@ decode_data] [@ CoreGraphics@0xa2900 ] [@ CoreGraphics@0x7faf3 ] [@ CoreGraphics@0x7fe6f ] [@ CoreGraphics@0x77b2f ] [@ CoreGraphics@0xa1af0 ]
status-firefox26: --- → affected
tracking-firefox24: --- → ?
Keywords: topcrash
(Reporter)

Comment 3

5 years ago
It accounts for 40% of Mac crashes in 24.0b1.
(Assignee)

Comment 4

5 years ago
The presence of libPDFRIP.dylib in the crash stacks suggests these crashes are happening when printing to a PDF file.  Also, the three stacks I looked at all have QTKit in their modules lists -- so this *might* have something to do with WebRTC (which uses QTKit).
(Assignee)

Comment 5

5 years ago
It'd be nice to have some URLs on which these crashes happen.
(Assignee)

Comment 6

5 years ago
> Also, the three stacks I looked at all have QTKit in their modules
> lists -- so this *might* have something to do with WebRTC (which
> uses QTKit).

I take this back.  QTKit shows up in gdb's "info sharedlibrary" list
even when FF is first started (with the about:home page showing).
(Assignee)

Comment 7

5 years ago
I found one crash report whose modules list has no brand-specific printer drivers (e.g. HP):

bp-7fb98612-3c1e-45d4-982f-9b6e32130813

So I doubt these crashes are due to a specific set of printer drivers.
(Reporter)

Updated

5 years ago
Keywords: needURLs
(Assignee)

Comment 8

5 years ago
Created attachment 790424 [details]
Breakpad stack with OS symbols translated

For what it's worth, I used atos to translate the symbols at the top of one of this bug's stack traces.  For some reason atos wouldn't translate any of the PrintCore symbols (even though that library definitely doesn't have its symbols stripped).

Needless to say (both from this stack and from all the stacks' crash addresses), these crashes look like the result of attempting to access a deleted object.
(Assignee)

Comment 9

5 years ago
I've often successfully used libgmalloc to figure out use-after-free bugs (http://developer.apple.com/library/mac/technotes/tn2124/_index.html#//apple_ref/doc/uid/DTS10003391-CH1-SECGMALLOC).

But just now I tried it with a current m-c nightly, FF 22 and FF 24b2, and had no luck.  So maybe this *isn't* a use-after-free bug.  Or maybe it's just that it only happens with certain pages.

So we really do need a list of URLs on which these crashes happen.

(By the way, libgmalloc may not work properly unless you also turn off jemalloc by setting the NO_MAC_JEMALLOC environment variable.)
Created attachment 790478 [details]
Gdb stack trace to CGSImageStreamRead

Here's a more accurate trace up to the call to CGSImageStreamRead.  I got this in gdb (with today's m-c nightly, running on OS X 10.8.4), printing to a PDF file (without crashing).
8 	http://webmail.muw.edu/horde/imp/view.php?thismailbox=INBOX&index=50&id=3&act...
6 	http://www.octoberresearch.com/pdf/CFPB_Two_Year_Special_Edition.pdf
3 	http://www.cote-azur.cnrs.fr/Services/Sfc/Documents/FICHE-DE-PROCEDURE-TRAITE...
3 	http://f.tlcollect.com/fr2/613/28331/13901_Van_Ness_Brochure.pdf
3 	https://member.bcbsm.com/mpa/person/809070405080305/eob/documentNumber/2013-0...
3 	http://www.sa.ucsb.edu/orientation/PDF/Directions/ParkingforTransferOrientati...
3 	http://sg.caseyresearch.com/wf/click?upn=5O6aHO8wtz4uJDsv32clzxM9oYR48aN3n0Kh...
3 	https://miside.uib.no/dotlrn/classes/det-medisinske-fakultet/medmbk/medmbk-20...
2 	https://mycheckfree.com/br/wps?rq=bfebv&b=20130724191039365351&py=00000000000...
2 	http://www.afip.gob.ar/genericos/guiaDeTramites/guia/documentos/GUIAPASOAPASO...
2 	http://www.tradepmr.com/Views/BrokerageServices/Forms/Individual_FCC.pdf
2 	https://hb.deltacommunitycu.com/axestatements/RetrieveDocument.aspx?pi=2F0034...
2 	http://c586449.r49.cf2.rackcdn.com/56381857-Scripture-Journal-Ideas.pdf
2 	http://www.thetrainline.com/buytickets/RenderPDF.aspx?token=NDU1Nzk1OTY2X1xcM...
2 	http://www.tailofthedragonmaps.com/maps/pdf/Diamondback_2011.pdf
2 	https://kerio.ssummit.org/webmail/api/download/attachment/0d4628e0-8fd0-4ac6-...
2 	https://doc-0g-60-docsviewer.googleusercontent.com/viewer/securedownload/ps9h...
2 	http://xa.yimg.com/kq/groups/2719057/1266107563/name/Santa-ma-jazz%2Epdf
2 	http://www.nhstateparks.org/uploads/pdf/Northwood-Meadows_Trail-Map_NALMC.pdf

The above are the urls that i could grab from crash-stats(https://crash-stats.mozilla.com/report/list?signature=decode_data).Most of the comments say that the crash happens while printing.

Steven, let us know if the problem is obvious or add qawanted if you want QA to give need reproduce this crash a shot ?
A lot of these URLs are truncated, and therefore useless.

But there are also some that aren't, and it's interesting that they're all PDF files.  I'll play around with them and see what I can find.
Bingo!  I just crashed twice in a row on the following URL:

http://www.octoberresearch.com/pdf/CFPB_Two_Year_Special_Edition.pdf

I waited until the PDF file had finished loading, then clicked on the Printer icon in the PDF.js display to print the file, and chose to save it to a PDF file.  I tested in FF 24b2 on OS X 10.8.4.
Created attachment 791336 [details]
Testcase
Total Count 	URL
11 	about:blank
8 	http://webmail.muw.edu/horde/imp/view.php?thismailbox=INBOX&index=50&id=3&actionID=113&mime=0e54d275d4ceda9df1b1c8bfe6b83d36
7 	http://www.octoberresearch.com/pdf/CFPB_Two_Year_Special_Edition.pdf
3 	http://f.tlcollect.com/fr2/613/28331/13901_Van_Ness_Brochure.pdf
3 	https://member.bcbsm.com/mpa/person/809070405080305/eob/documentNumber/2013-08-09-1.pdf
3 	http://www.sa.ucsb.edu/orientation/PDF/Directions/ParkingforTransferOrientation.pdf
3 	https://miside.uib.no/dotlrn/classes/det-medisinske-fakultet/medmbk/medmbk-2013h/file-storage/download/110850559/Nyrefunksjon+_Proteinuri,_H2013-2.pdf
3 	https://miside.uib.no/dotlrn/classes/det-medisinske-fakultet/medmbk/medmbk-2013h/file-storage/download/110850559/Nyrefunksjon+_Proteinuri,_H2013-2.pdf
3 	http://sg.caseyresearch.com/wf/click?upn=5O6aHO8wtz4uJDsv32clzxM9oYR48aN3n0Khz7NCZueomMAQDOofgJXQTMHCDBvBXP2mgR-2Bp8HHTtxFa-2B4l0KQ-3D-3D_h5t0sXMHY-2BTUyw0GikL8xav1mBaN3oSnpnD6o3Mg15aOj9mi5CtHyMyaO-2FkHWW947uCARqexyIF-2F2xk6LCA-2BURnmpREhUXiud7xYon1BKlzwg
2 	https://hb.deltacommunitycu.com/axestatements/RetrieveDocument.aspx?pi=2F003403DD55346CB965DFA6EB2ADEA417A90D25A198F6B135FABEFE7AD033C7704F4E04320EBBDC08E1DEF7B7582689AC6F84B09593BF88A9D8B4D6806440C42740640AD700B085
2 	https://mycheckfree.com/br/wps?rq=bfebv&b=20130724191039365351&py=000000000000001&.done=wps%3Frq%3Dbfbl%26oss%3D670c6595868f730b02b07ac503cee84f552d8776ecc61faf%26esc%3D93096239%26osn%3D670c6595868f730b02b07ac503cee84f552d8776ecc61faf%26lm%3Dd%26sp%3D1000
2 	http://www.thetrainline.com/buytickets/RenderPDF.aspx?token=NDU1Nzk1OTY2X1xcMTAuMjQ0LjEwOS4zOFxQREZzLzIyNWJiNzdkLTc1ZDgtNDBkMy1hZTY2LTRjZDFmYTc4MzA3ZC5wZGZ0aXNzaXBFTUFJTFNlY3JldEtFWUZvckJvb2tpbmdJRA==
2 	http://www.tailofthedragonmaps.com/maps/pdf/Diamondback_2011.pdf
2 	http://192.168.0.198/hoyoujyo/file/kawana-map.pdf
2 	http://www.tradepmr.com/Views/BrokerageServices/Forms/Individual_FCC.pdf
2 	http://c586449.r49.cf2.rackcdn.com/56381857-Scripture-Journal-Ideas.pdf
Keywords: needURLs
STR:

1) Visit https://bugzilla.mozilla.org/attachment.cgi?id=791336 and wait til it finishes loading into PDF.js.
2) Click on the PDF.js printer icon.
3) In the OS print dialog, choose PDF : Save as PDF.
4) Click on the Save button, and if prompted choose to replace an existing file.
5) Wait 15-20 seconds and you should crash.
Keywords: reproducible
Whiteboard: STR in comment #16

Updated

5 years ago
tracking-firefox24: ? → +
tracking-firefox25: --- → +
Steven, passing this on to you, please feel free to reassign if needed.
Assignee: nobody → smichaud
Created attachment 791352 [details]
Gdb all thread stack trace, made on OS X 10.8.4

These crashes still happen in today's mozilla-central nightly.
Actually my testcase isn't perfect.  Even though (according to Socorro) these crashes go back to FF 22 (or even perhaps FF 21), I only crash with it consistently on the 24 branch and up.  On FF 23 I haven't crashed once, and on FF 22 and 21 I see the following error message in a sheet (presumably instead of crashing):

Print Preview Error
An error occurred while printing.

So I'll need to look for another, better testcase, with which I can look for a regression range.
Created attachment 791378 [details]
Another, better testcase

This testcase crashes for me back to FF 22 on OS X 10.8.4 (though not in FF 21).  This might have something to do with the fact that I see a "This PDF document might not be displayed correctly" error with this testcase, which I didn't see with the previous one.
Attachment #791336 - Attachment is obsolete: true
I should have mentioned that the original of my second testcase is here:
http://www.sa.ucsb.edu/orientation/PDF/Directions/ParkingforTransferOrientation.pdf
Revised STR:

1) Visit the link in this bug's URL field and wait til it finishes loading into PDF.js.
2) Click on the PDF.js printer icon.
3) In the OS print dialog, choose PDF : Save as PDF.
4) Click on the Save button, and if prompted choose to replace an existing file.
5) Wait 15-20 seconds and you should crash.
Whiteboard: STR in comment #16 → STR in comment #22
With my testcase from comment #20, I've found the following regression range:

firefox-2013-05-17-03-10-00-mozilla-central
firefox-2013-05-18-03-11-14-mozilla-central
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ea767da526ff&tochange=6e2789a70f6b
Here I suspect the following patch:

http://hg.mozilla.org/mozilla-central/rev/aaf5d70ba693

 Bug 871530 - Update pdf.js to version 0.8.169. r=dtownsend
author	Ryan VanderMeulen <ryanvm@gmail.com>
	Fri May 17 16:46:26 2013 -0400 (at Fri May 17 16:46:26 2013 -0400)

I'll try to confirm this.
> I'll try to confirm this.

I've confirmed that the patch for bug 871530 triggered these crashes (at least most of them).
Blocks: 871530
Out of curiosity, I tried printing my testcase from comment #20 from FF 22 and 23 on Windows 7.  I didn't crash or see any other problems.

This was to a real printer.  But I crash printing to the same printer using FF 22 and up on OS X 10.8.4.
Even though these crashes are (apparently) a Mac-only problem, we should consider backing out the patch for bug 871530 right away on the 24 branch -- if only to give us time to find out if *that* will have any bad effects.
It's not unlikely that the true cause of these crashes is bugs in Apple's printing code -- though it's a bit surprising that the bugs would exist in all three supported versions of OS X (10.6, 10.7 and 10.8),

But even if the crashes are at least partly Apple's fault, it'll probably take a long time to find Apple's bugs.  And it's very unlikely that we'll be able to do this before the FF 24 release.
Someone who knows more about PDF.js that I do should try randomly disabling parts of it, to see what might be causing trouble on our side.
> Someone who knows more about PDF.js that I do should try randomly
> disabling parts of it

Or parts of the patch for bug 871530.
Ryan, could you do what I suggest in comment #29 and comment #29?  Or do you know someone else who might do it?
Flags: needinfo?(ryanvm)
bdahl or yury would be a good start to ask
Flags: needinfo?(ydelendik)
Flags: needinfo?(ryanvm)
Flags: needinfo?(bdahl)
Created attachment 791623 [details]
Minimal test case to replicate the issue

The problem is with re-using the same canvas when creating patterns (part of the reducing memory used by the pdf.js). It works fine with regular canvas 2d context, fails with generated by mozPrintCallback context on Mac OSX. (Looks like bug 890730 is related to this one)
Flags: needinfo?(ydelendik)
Flags: needinfo?(bdahl)
New steps to replicate:

1) Visit https://bugzilla.mozilla.org/attachment.cgi?id=791623 .
2) Print the page (Cmd + P or link as the bottom of the page).
3) In the OS print dialog, choose PDF : Save as PDF.
4) Click on the Save button, and if prompted choose to replace an existing file.
5) Wait 15-20 seconds and you should crash.

Updated

5 years ago
Whiteboard: STR in comment #22 → STR in comment #35
Sounds like this bug and bug 890730 will be very difficult to "fix", since they're probably Apple's fault.  But how about working around them (in PDF.js) by special-casing printing on OS X -- by not re-using a canvas to create patterns when printing on OS X?
Flags: needinfo?(ydelendik)
(In reply to Steven Michaud from comment #36)
> Sounds like this bug and bug 890730 will be very difficult to "fix", since
> they're probably Apple's fault.  But how about working around them (in
> PDF.js) by special-casing printing on OS X -- by not re-using a canvas to
> create patterns when printing on OS X?

We can provide workaround(s) for beta (and aurora?) as a temporary solution and will not be okay for long run: producing lots of canvases (some pages might have be hundreds of them) in short period of time will not be good for large documents.

Also I'm not convinced that it's not a firefox (e.g. mozPrintCallback) printing defect for the Mac OSX. Can you confirm that it's indeed Apple's fault.
> We can provide workaround(s) for beta (and aurora?) as a temporary
> solution

Please do.

> and will not be okay for long run

No, I suppose not.  But it may take us a while to figure out this bug
(and bug 890730), and in the meantime a workaround is better than
leaving this bug unfixed.

> Can you confirm that it's indeed Apple's fault.

No.  But Apple only very rarely acknowledges its bugs -- especially if
they don't effect "their" products (like Safari).  So the burden of
"proof" rests entirely on us, and (since these crashes happen in
system code) it will require extensive reverse engineering, which is
likely to take a long time.

Furthermore, even I'm not *sure* this is an Apple bug.  I just think
it's likely on the face of it.

But even if this *is* our bug, it'll still take a long time to find,
since we're not crashing in FF code.
(Assignee)

Updated

5 years ago
Flags: needinfo?(ydelendik)
Created attachment 794334 [details] [diff] [review]
avoiding crash on Mac (ff24)
Attachment #794334 - Flags: review?(bdahl)
Created attachment 794335 [details] [diff] [review]
avoiding crash on Mac (ff25)
Attachment #794335 - Flags: review?(bdahl)
In nightly, pdf.js was changed to handle patterns properly (bug 903452, https://github.com/mozilla/pdf.js/commit/2aecbe874e8aca89ea14759ea41665f10eafb5fd) so it's impossible to replicate the issue using steps in comment 22 -- the steps in comment 35 must be used. That's not a fix for the crash issue.

Updated

5 years ago
Attachment #794334 - Flags: review?(bdahl) → review+

Updated

5 years ago
Attachment #794335 - Flags: review?(bdahl) → review+
Comment on attachment 794334 [details] [diff] [review]
avoiding crash on Mac (ff24)

[Approval Request Comment]
Bug caused by (feature/regressing bug #): mozPrintCallback
User impact if declined: mac browser will crash when certain pdfs are printed
Testing completed (on m-c, etc.): https://tbpl.mozilla.org/?tree=Try&rev=ed6cbdaa14c1
Risk to taking this patch (and alternatives if risky): minimal, related to the performance, and specific only to pdf viewer functionality
String or IDL/UUID changes made by this patch: None
Attachment #794334 - Flags: approval-mozilla-beta?
Comment on attachment 794335 [details] [diff] [review]
avoiding crash on Mac (ff25)

[Approval Request Comment]
Bug caused by (feature/regressing bug #): mozPrintCallback
User impact if declined: mac browser will crash when certain pdfs are printed
Testing completed (on m-c, etc.): https://tbpl.mozilla.org/?tree=Try&rev=21ea7603ffa0
Risk to taking this patch (and alternatives if risky): minimal, related to the performance, and specific only to pdf viewer functionality
String or IDL/UUID changes made by this patch: None
Attachment #794335 - Flags: approval-mozilla-aurora?
(In reply to Yury Delendik (:yury) from comment #42)
> In nightly, pdf.js was changed to handle patterns properly (bug 903452,
> https://github.com/mozilla/pdf.js/commit/
> 2aecbe874e8aca89ea14759ea41665f10eafb5fd) so it's impossible to replicate
> the issue using steps in comment 22 -- the steps in comment 35 must be used.
> That's not a fix for the crash issue.

So fx-26 is unaffected at all and no patch is needed there or would it need an alternate one ?
> So fx-26 is unaffected at all and no patch is needed there or would it need an alternate one ?

It will need a fix for the mozPrintCallback functionality for Mac OS X (see comment 38). These two patches will just buy us time to fix the issue properly.
> So fx-26 is unaffected

It's still affected, but you cannot replicate that using steps in comment 22. It still can crash on other pdfs.
Comment on attachment 794334 [details] [diff] [review]
avoiding crash on Mac (ff24)

low risk, helps fix top-crash
Attachment #794334 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Updated

5 years ago
Attachment #794335 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(In reply to bhavana bajaj [:bajaj] from comment #48)
> Comment on attachment 794334 [details] [diff] [review]
> avoiding crash on Mac (ff24)
> 
> low risk, helps fix top-crash
(In reply to Yury Delendik (:yury) from comment #47)
> > So fx-26 is unaffected
> 
> It's still affected, but you cannot replicate that using steps in comment
> 22. It still can crash on other pdfs.

OK, so i am tracking for Fx26 in that case.

Also was the patch applied to beta branch and verified or do you need any additional QA help here ?
tracking-firefox26: --- → +

Updated

5 years ago
Keywords: checkin-needed
Whiteboard: STR in comment #35 → STR in comment #35 [leave-open] checkin needed for ff24 and ff25 patches
(In reply to bhavana bajaj [:bajaj] from comment #50)
 
> Also was the patch applied to beta branch and verified or do you need any
> additional QA help here ?

The patches where tested with STR from comment 22. However it will be nice to verify if all documents listed in comment 11 affected as well.
I just crash Nightly (2013-08-26) with one of the pdf's in comment #11; http://www.tailofthedragonmaps.com/maps/pdf/Diamondback_2011.pdf
It was the first one I randomly tried.
As best I can tell the aurora and beta branch patches haven't landed yet.

And in any case this bug is (currently) only being "fixed" (worked around) on the aurora and beta branches.  For the time being we're leaving it unfixed (i.e. not worked around) on the trunk in the hope that we'll be able to find a more narrowly defined bug (ours or Apple's) that we can fix, or work around more neatly.
https://hg.mozilla.org/releases/mozilla-aurora/rev/e51ab0350b5a
https://hg.mozilla.org/releases/mozilla-beta/rev/4e1a0fe2e673

Calling this "fixed" for 24/25.
status-firefox21: affected → wontfix
status-firefox22: affected → wontfix
status-firefox23: affected → wontfix
status-firefox24: affected → fixed
status-firefox25: affected → fixed
Keywords: checkin-needed
Whiteboard: STR in comment #35 [leave-open] checkin needed for ff24 and ff25 patches → [leave-open] STR in comment #35

Updated

5 years ago
Keywords: verifyme
I just crashed in this bug with 24b10 - https://crash-stats.mozilla.com/report/index/7734125a-9f19-4915-a421-ffba52130913

Also crashed with Aurora nightly of 20130913 (no crash reporter, hmmm?)

Using a Mac 10.6.8 machine.
status-firefox24: fixed → affected
status-firefox25: fixed → affected
Do you have STR?

I see a few post-Yury's-patch crashes at https://crash-stats.mozilla.com.  But the patch seems to caused their frequency to decrease substantially.
Steven, I was using STR in comment #35.  

It concerns me that no crash reporter for Aurora appeared.  (could explain fewer reports, at least on that channel)
We have a problem :-(

I crash consistently with the STR from comment #35, on OS X 10.6.8 and 10.8.5, in FF24b10 and today's mozilla-central nightly.

Yury, it looks like you may have to revise your workaround, or come up with another one.

There may also be other, recently introduced factors.  But if these crashes still happen on beta and trunk, that seems unlikely.  Just in case, though, I'll look for regression ranges post-Yury's-patch.
Flags: needinfo?(ydelendik)
> and today's mozilla-central nightly

Oops, forgot that trunk *doesn't* have Yury's patch.
I also crash consistently in today's mozilla-aurora nightly (with the STR from comment #35), on OS X 10.8.5.
Forgot to mention that I always saw the crash reporter with my Aurora crashes.
> Just in case, though, I'll look for regression ranges post-Yury's-patch.

I can easily reproduce these crashes (using the STR from comment #35, on OS X 10.8.5) with the 2013-08-27-00-40-06-mozilla-aurora nightly -- the first Aurora nightly to contain Yury's patch.

Unfortunately I can't reproduce these crashes (using comment #35's STR) with any of the "debug" nightlies (including the mozilla-central-debug ones).  So there's no point testing with the mozilla-beta-debug nightlies.
As the patch for bug 871530 triggered these crashes (see comment #24), I think we should consider backing it out on beta and aurora if we can't come up with a better workaround.
fortunately, the signatures are not in the top 300 on Beta or Aurora and combined don't qualify for platform topcrasher.
Keywords: topcrash
(In reply to Steven Michaud from comment #58)
> We have a problem :-(
> 
> I crash consistently with the STR from comment #35, on OS X 10.6.8 and
> 10.8.5, in FF24b10 and today's mozilla-central nightly.
> 
> Yury, it looks like you may have to revise your workaround, or come up with
> another one.
> 
> There may also be other, recently introduced factors.  But if these crashes
> still happen on beta and trunk, that seems unlikely.  Just in case, though,
> I'll look for regression ranges post-Yury's-patch.

Steven,

Not sure what you are asking. I provided workaround for PDF.js. STR in comment #35 use regular HTML page and show that problem with the Gecko's mozPrintCallback and not PDF.js itself.

And yes, you have to crash consistently with attachment 791623 [details] until the issue on Mac OSX is resolved.
Flags: needinfo?(ydelendik)
OK, I misunderstood.  Thanks, Yury.

Note, everyone, that the testcase for this bug (in comment #35) is *not* a testcase for Yury's workaround.  And judging from comment #45, my "parking lot" testcase from comment #22 isn't either.

We'll need to keep an eye on the frequency of this bug's crashes in FF 24.

It'd also help to get another set of crash URLs for builds that contain Yury's patch -- FF 24b6 and later (I think), plus 25-branch nightlies dated 2013-08-27 and later.  Tracy, could you do that?
Flags: needinfo?(twalker)
It's not possible to sort out URLs by (range of) builds.

Updated

5 years ago
Flags: needinfo?(twalker)
> It's not possible to sort out URLs by (range of) builds.

Can you do URLs by release version?  If so, please do so for the FF 24 release.
Flags: needinfo?(twalker)
Socorro cannot do that either, sorry.
Flags: needinfo?(twalker)

Comment 70

5 years ago
(In reply to Tracy Walker [:tracy] from comment #69)
> Socorro cannot do that either, sorry.

Actually, I think that works, but we have very little data for now:
https://crash-stats.mozilla.com/report/list?product=Firefox&range_value=7&range_unit=days&date=2013-09-23&signature=decode_data&version=Firefox%3A24.0
This signature is no longer showing up in the top-300 crash report for Firefox 24.0, 25.0b, and 26.0a2; it's currently at #87 (0.12%) on Firefox 27.0a1. Can we call this fixed based on this data?
> Can we call this fixed based on this data?

I think it's best to leave this bug open, since we still don't know the underlying cause.

But it's a relief to see that Yury's patch seems to have made it much less urgent.  Though we still need to keep our eyes open.
Fair enough.
Keywords: verifyme

Comment 74

5 years ago
Thanks!
Current Ranking:
 * @ decode_data only shows up on Aurora and ranks #251st
 * @ CoreGraphics shows up at #128 on Nightly, #72 on Aurora, not at all on Beta, and not at all on Release

Note that the signature showing up on Nightly and Aurora is CoreGraphics@0x7fb9b which does not appear to be covered by this bug. I'm not sure what can be determined about the state of this bug from this data.
> CoreGraphics@0x7fb9b

I think this does belong here.  I've been meaning to add it, but hadn't yet gotten around to it.
Crash Signature: [@ decode_data] [@ CoreGraphics@0xa2900 ] [@ CoreGraphics@0x7faf3 ] [@ CoreGraphics@0x7fe6f ] [@ CoreGraphics@0x77b2f ] [@ CoreGraphics@0xa1af0 ] → [@ decode_data] [@ CoreGraphics@0xa2900 ] [@ CoreGraphics@0x7faf3 ] [@ CoreGraphics@0x7fe6f ] [@ CoreGraphics@0x77b2f ] [@ CoreGraphics@0xa1af0 ] [@ CoreGraphics@0x7fb9b ]
> CoreGraphics@0x7fb9b

On second thought I'm not so sure.

These go back a long way -- at least to FF 19.0.2.  But this bug as originally reported started with FF 24 (and was triggered by the patch for bug 871530, as reported in comment #24 and comment #25).  And these crashes continue to happen in significant numbers on the trunk (currently the 27 branch).

I'm almost certain they're related.  But they're different enough to deserve their own bug.  I'll open one.
Crash Signature: [@ decode_data] [@ CoreGraphics@0xa2900 ] [@ CoreGraphics@0x7faf3 ] [@ CoreGraphics@0x7fe6f ] [@ CoreGraphics@0x77b2f ] [@ CoreGraphics@0xa1af0 ] [@ CoreGraphics@0x7fb9b ] → [@ decode_data] [@ CoreGraphics@0xa2900 ] [@ CoreGraphics@0x7faf3 ] [@ CoreGraphics@0x7fe6f ] [@ CoreGraphics@0x77b2f ] [@ CoreGraphics@0xa1af0 ]
(Assignee)

Updated

5 years ago
See Also: → bug 925448
> I'll open one.

I've opened bug 925448.
(Assignee)

Updated

5 years ago
See Also: → bug 932077
Steven - there are STR in comment #35 and this is marked as still affected on FF26 which is in its second week of Beta - what's the plan here?  What are the next steps?  Is there anything you need help with from QA?  This isn't marked as a topcrash so should we still be tracking this longtime crash issue?
Flags: needinfo?(smichaud)
I hope soon to have a real fix for this, along with bug 925448 and bug 932077.  I'm working on it at bug 925448.  By "soon" in mean in the next 2-3 days.  Whatever I come up with may take a while to review, and will (of course) need to bake for at least a little while on the trunk.

If that's not soon enough for FF 26, I suggest landing Yuri's workaround there.
Flags: needinfo?(smichaud)
I've now got a fix for this bug at bug 925448.  But it may take a few days (or longer) to get review(s).  Given that the FF 26 release is so close (just one more beta), I think we should land Yury's workaround there now.  If it turns out my patch gets reviewed in time, it can still land together with Yury's workaround -- doing that shouldn't cause any trouble.

What do people think?
Flags: needinfo?(ydelendik)
Flags: needinfo?(lsblakk)
Created attachment 8336831 [details] [diff] [review]
avoiding crash on Mac (ff26)

[Approval Request Comment]
Bug caused by (feature/regressing bug #): mozPrintCallback
User impact if declined: mac browser will crash when certain pdfs are printed
Testing completed (on m-c, etc.): similar patches are part of ff24 and ff25
Risk to taking this patch (and alternatives if risky): minimal, related to the performance, and specific only to pdf viewer functionality
String or IDL/UUID changes made by this patch: None

Patch is similar to previous patches. Build is available at https://tbpl.mozilla.org/?tree=Try&rev=f1c5c9d3bad1
Attachment #8336831 - Flags: review?(bdahl)
Attachment #8336831 - Flags: approval-mozilla-beta?
Flags: needinfo?(ydelendik)
(In reply to Steven Michaud from comment #81)
> I've now got a fix for this bug at bug 925448.  But it may take a few days
> (or longer) to get review(s).  Given that the FF 26 release is so close
> (just one more beta), I think we should land Yury's workaround there now. 
> If it turns out my patch gets reviewed in time, it can still land together
> with Yury's workaround -- doing that shouldn't cause any trouble.
> 
> What do people think?

Yes, let's go with the known-good fix here for 26, will approve for uplift.
Flags: needinfo?(lsblakk)
(once r+ granted)

Updated

5 years ago
Attachment #8336831 - Flags: review?(bdahl) → review+
Attachment #8336831 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Updated

5 years ago
Keywords: checkin-needed
Whiteboard: [leave-open] STR in comment #35 → [leave-open] STR in comment #35; checkin needed for the ff26 patch
https://hg.mozilla.org/releases/mozilla-beta/rev/eade2a8b6c7e
status-firefox24: affected → fixed
status-firefox25: affected → fixed
status-firefox26: affected → fixed
Keywords: checkin-needed
Whiteboard: [leave-open] STR in comment #35; checkin needed for the ff26 patch → [leave-open] STR in comment #35;
status-b2g-v1.2: --- → fixed

Updated

5 years ago
Keywords: verifyme
I can still crash Firefox 26 beta 8 using STR from comment 35
https://crash-stats.mozilla.com/report/index/64449c4e-b0db-450b-9799-392062131126
https://crash-stats.mozilla.com/report/index/246ce7ff-4f9e-41fd-8f44-3d2a02131126
Are this the correct STR in order to verify Yury's workaround for Firefox 26?
Flags: needinfo?(smichaud)
(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #87)
> I can still crash Firefox 26 beta 8 using STR from comment 35
> https://crash-stats.mozilla.com/report/index/64449c4e-b0db-450b-9799-
> 392062131126
> https://crash-stats.mozilla.com/report/index/246ce7ff-4f9e-41fd-8f44-
> 3d2a02131126
> Are this the correct STR in order to verify Yury's workaround for Firefox 26?

See comment 51 and comment 65
Yes, Yury's right.  His workaround decreases the frequency of these crashes, but doesn't eliminate them.  See also bug 925448 comment #14.

I have a true fix for this bug (and bug 932077) at bug 925448, now r+ed, which I'll land on mozilla-inbound later today.  But, though it's low to moderate risk, I suspect it's too late to land it on the 26 branch.  In any case we need to let it bake for a while.

You'll have to ask Yury for STR to verify his workaround.
Flags: needinfo?(smichaud)
> You'll have to ask Yury for STR to verify his workaround.
Flags: needinfo?(ydelendik)
(In reply to Steven Michaud from comment #90)
> > You'll have to ask Yury for STR to verify his workaround.

As I mentioned in the comment 51, STR can be found in comment 22:

1) Visit the link in this bug's URL field and wait til it finishes loading into PDF.js.
2) Click on the PDF.js printer icon.
3) In the OS print dialog, choose PDF : Save as PDF.
4) Click on the Save button, and if prompted choose to replace an existing file.
5) Wait 15-20 seconds and you should crash.
 
It will be nice to verify if all documents listed in comment 11 affected as well.
Flags: needinfo?(ydelendik)
Thanks Yury and Steven. Using STR from comment 22 and using the URLs from comment 11 I was not able to crash Firefox 26 beta 8 on Mac OS X 10.8.5
status-firefox26: fixed → verified
Socorro has no crashes for this bug in 28-branch builds dated 2013-11-27 or later (which contain the patch for bug 925448).  So I'm going to say this bug was fixed by the patch for bug 925448.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Updated

5 years ago
status-firefox28: --- → fixed
(Assignee)

Updated

5 years ago
status-firefox27: --- → affected
(Assignee)

Updated

5 years ago
Whiteboard: [leave-open] STR in comment #35; → STR in comment #35;
Depends on: 925448
Target Milestone: --- → mozilla28
Bug 925448 was uplifted to Aurora (Fx27) as well.
status-firefox27: affected → fixed

Comment 97

5 years ago
Verified as fixed on Firefox 27.0b1 and 28.0a2 (12/11) with the steps from comment 35 (the only steps I could reproduce the issue with on Firefox 23).
Status: RESOLVED → VERIFIED
status-firefox27: fixed → verified
status-firefox28: fixed → verified
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.