880140 - crash in nsDeviceContextSpecX::EndPage @ decode_data when printing

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Scoobidiver (away)]

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

Comment 1

[Scoobidiver (away)]

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

Comment 2

[Scoobidiver (away)]

It's #10 browser crasher in 23.0 and #1 in 24.0b1 on Mac OS X.

Comment 3

[Scoobidiver (away)]

It accounts for 40% of Mac crashes in 24.0b1.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

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

Comment 5

[Steven Michaud [:smichaud] (Retired)]

It'd be nice to have some URLs on which these crashes happen.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

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

Comment 7

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

Attachment: 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.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

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

Comment 10

[Steven Michaud [:smichaud] (Retired)]

Attachment: 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).

Comment 11

[bhavana bajaj [:bajaj]]

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 ?

Comment 12

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

Attachment: Testcase

Comment 15

[Tracy Walker [:tracy]]

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

Comment 16

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 17

[bhavana bajaj [:bajaj]]

Steven, passing this on to you, please feel free to reassign if needed.

Comment 18

[Steven Michaud [:smichaud] (Retired)]

Attachment: Gdb all thread stack trace, made on OS X 10.8.4

These crashes still happen in today's mozilla-central nightly.

Comment 19

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 20

[Steven Michaud [:smichaud] (Retired)]

Attachment: 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.

Comment 21

[Steven Michaud [:smichaud] (Retired)]

I should have mentioned that the original of my second testcase is here:
http://www.sa.ucsb.edu/orientation/PDF/Directions/ParkingforTransferOrientation.pdf

Comment 22

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 23

[Steven Michaud [:smichaud] (Retired)]

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

Comment 24

[Steven Michaud [:smichaud] (Retired)]

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 <[e-mail]>
	Fri May 17 16:46:26 2013 -0400 (at Fri May 17 16:46:26 2013 -0400)

I'll try to confirm this.

Comment 25

[Steven Michaud [:smichaud] (Retired)]

> I'll try to confirm this.

I've confirmed that the patch for bug 871530 triggered these crashes (at least most of them).

Comment 26

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 27

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 28

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 29

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 30

[Steven Michaud [:smichaud] (Retired)]

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

Comment 31

[Steven Michaud [:smichaud] (Retired)]

Ryan, could you do what I suggest in comment #29 and comment #29?  Or do you know someone else who might do it?

Comment 32

[Steven Michaud [:smichaud] (Retired)]

> comment #29 and comment #29

comment #29 and comment #30

Comment 33

[Ryan VanderMeulen [:RyanVM]]

bdahl or yury would be a good start to ask

Comment 34

[Yury Delendik (:yury)]

Attachment: 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)

Comment 35

[Yury Delendik (:yury)]

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.

Comment 36

[Steven Michaud [:smichaud] (Retired)]

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?

Comment 37

[Yury Delendik (:yury)]

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

Comment 38

[Steven Michaud [:smichaud] (Retired)]

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

Comment 39

[Yury Delendik (:yury)]

Attachment: avoiding crash on Mac (ff24)

Comment 40

[Yury Delendik (:yury)]

Attachment: avoiding crash on Mac (ff25)

Comment 41

[Yury Delendik (:yury)]

Try builds:
* for beta - https://tbpl.mozilla.org/?tree=Try&rev=ed6cbdaa14c1
* for aurora - https://tbpl.mozilla.org/?tree=Try&rev=21ea7603ffa0

Comment 42

[Yury Delendik (:yury)]

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.

Comment 43

[Yury Delendik (:yury)]

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

Comment 44

[Yury Delendik (:yury)]

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

Comment 45

[bhavana bajaj [:bajaj]]

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

Comment 46

[Yury Delendik (:yury)]

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

Comment 47

[Yury Delendik (:yury)]

> 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 48

[bhavana bajaj [:bajaj]]

Comment on attachment 794334 [details] [diff] [review]
avoiding crash on Mac (ff24)

low risk, helps fix top-crash

Comment 49

[bhavana bajaj [:bajaj]]

(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

Comment 50

[bhavana bajaj [:bajaj]]

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

Comment 51

[Yury Delendik (:yury)]

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

Comment 52

[Tracy Walker [:tracy]]

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.

Comment 53

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 54

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e51ab0350b5a
https://hg.mozilla.org/releases/mozilla-beta/rev/4e1a0fe2e673

Calling this "fixed" for 24/25.

Comment 55

[Tracy Walker [:tracy]]

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.

Comment 56

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 57

[Tracy Walker [:tracy]]

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)

Comment 58

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 59

[Steven Michaud [:smichaud] (Retired)]

> and today's mozilla-central nightly

Oops, forgot that trunk *doesn't* have Yury's patch.

Comment 60

[Steven Michaud [:smichaud] (Retired)]

I also crash consistently in today's mozilla-aurora nightly (with the STR from comment #35), on OS X 10.8.5.

Comment 61

[Steven Michaud [:smichaud] (Retired)]

Forgot to mention that I always saw the crash reporter with my Aurora crashes.

Comment 62

[Steven Michaud [:smichaud] (Retired)]

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

Comment 63

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 64

[Tracy Walker [:tracy]]

fortunately, the signatures are not in the top 300 on Beta or Aurora and combined don't qualify for platform topcrasher.

Comment 65

[Yury Delendik (:yury)]

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

Comment 66

[Steven Michaud [:smichaud] (Retired)]

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?

Comment 67

[Tracy Walker [:tracy]]

It's not possible to sort out URLs by (range of) builds.

Comment 68

[Steven Michaud [:smichaud] (Retired)]

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

Comment 69

[Tracy Walker [:tracy]]

Socorro cannot do that either, sorry.

Comment 70

[Robert Kaiser]

(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

Comment 71

[u279076]

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?

Comment 72

[Steven Michaud [:smichaud] (Retired)]

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

Comment 73

[u279076]

Fair enough.

Comment 74

[Kyle Wooten]

Thanks!

Comment 75

[u279076]

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.

Comment 76

[Steven Michaud [:smichaud] (Retired)]

> CoreGraphics@0x7fb9b

I think this does belong here.  I've been meaning to add it, but hadn't yet gotten around to it.

Comment 77

[Steven Michaud [:smichaud] (Retired)]

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

Comment 78

[Steven Michaud [:smichaud] (Retired)]

> I'll open one.

I've opened bug 925448.

Comment 79

[Lukas Blakk [:lsblakk] use ?needinfo]

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?

Comment 80

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 81

[Steven Michaud [:smichaud] (Retired)]

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?

Comment 82

[Yury Delendik (:yury)]

Attachment: 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

Comment 83

[Lukas Blakk [:lsblakk] use ?needinfo]

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

Comment 84

[Lukas Blakk [:lsblakk] use ?needinfo]

(once r+ granted)

Comment 85

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/eade2a8b6c7e

Comment 86

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/eade2a8b6c7e

Comment 87

[Bogdan Maris, Desktop QA]

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?

Comment 88

[Yury Delendik (:yury)]

(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

Comment 89

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 90

[Steven Michaud [:smichaud] (Retired)]

> You'll have to ask Yury for STR to verify his workaround.

Comment 91

[Steven Michaud [:smichaud] (Retired)]

> See also bug 925448 comment #14.

See also bug 925448 comment #13.

Comment 92

[Yury Delendik (:yury)]

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

Comment 93

[Bogdan Maris, Desktop QA]

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

Comment 94

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 95

[Ryan VanderMeulen [:RyanVM]]

Bug 925448 was uplifted to Aurora (Fx27) as well.

Comment 96

[Ioana (away)]

No post-fix crashes in Socorro:
https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&reason_type=contains&date=2013-12-11&range_value=28&range_unit=days&hang_type=any&process_type=any&signature=decode_data
https://crash-stats.mozilla.com/report/list?signature=CoreGraphics%400xa2900&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&hang_type=any&date=2013-12-11+13%3A00%3A00&range_value=4#reports
https://crash-stats.mozilla.com/report/list?signature=CoreGraphics%400x7faf3&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&hang_type=any&date=2013-12-11+13%3A00%3A00&range_value=4#reports
https://crash-stats.mozilla.com/report/list?signature=CoreGraphics%400x7fe6f&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&hang_type=any&date=2013-12-11+13%3A00%3A00&range_value=4#reports
https://crash-stats.mozilla.com/report/list?signature=CoreGraphics%400xa1af0&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&hang_type=any&date=2013-12-11+13%3A00%3A00&range_value=4#reports
https://crash-stats.mozilla.com/query/?product=Firefox&version=ALL%3AALL&range_value=4&range_unit=weeks&date=12%2F11%2F2013+13%3A00%3A00&query_search=signature&query_type=contains&query=CoreGraphics%400x77b2f&reason=&release_channels=&build_id=&process_type=any&hang_type=any

Comment 97

[Ioana (away)]

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