534672 - [10.6] Print crash on Snow Leopard [@ layout_flush_block] or [@ libPDFRIP.A.dylib@0x181c2 ] on 1.9.1 and 1.9.2, or on 2.0 with gfx.force_atsui_text turned on

Status: VERIFIED WORKSFORME

(Core :: Printing: Output, defect)

Description

[Dan Leehr]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5

First discovered when trying to print some confluence documents, certain lines would cause Firefox to crash when attempting to print or print preview.

This issue occurs in Mac OS X 10.6.2 Snow Leopard and Firefox 3.5.5.
Firefox is running in 32-bit x86 mode, SL in both 32- and 64-bit kernels

The issue seems to be related to how the words in the document wrap to the next line.  Adding or deleting characters before the margin can stop the problem from happening.

Reproducible: Always

Steps to Reproduce:
1. Launch Firefox 3.5.5 on Snow Leopard
2. Visit http://dl.dropbox.com/u/15577/firecrash.html
3. Click File->Print
4. Click Preview, Print, or PDF->Save as PDF
Actual Results:  
Firefox crashes

Expected Results:  
Print preview or actual print output is expected

Tested on several macs running 10.6.2 - Mac Pro early 2008 8x2.8, Macbook Pro 13" unibody, Mac Mini Core 2 Duo

Comment 1

[Daniel Holbert [:dholbert]]

Confirmed with Firefox 3.5.5:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
http://crash-stats.mozilla.com/report/index/bp-47dccc55-2204-4edf-a123-a50872091214

However, I don't get any crash in my mozilla-central nightly:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20091209 Minefield/3.7a1pre

I'm choosing "Preview" from print dialog.  Platform is a mac mini core 2 duo, running 10.6.2.  I don't have any printers configured.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (original)

Here's the testcase that bug reporter provided in the URL field.

Comment 3

[timeless]

Signature	layout_flush_block
UUID	47dccc55-2204-4edf-a123-a50872091214
Time 	2009-12-14 11:32:20.750119
Uptime	62
Product	Firefox
Version	3.5.5
Build ID	20091102134505
Branch	1.9.1
OS	Mac OS X
OS Version	10.6.2 10C540
CPU	x86
CPU Info	GenuineIntel family 6 model 7 stepping 10
Crash Reason	EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE
Crash Address	0x173ab1c2
User Comments	testing bug 534672
Processor Notes 	
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	libPDFRIP.A.dylib 	layout_flush_block 	
1 	libPDFRIP.A.dylib 	PDFTextLayoutFlush 	
2 	libPDFRIP.A.dylib 	PDFContentStreamDrawGlyphs 	
3 	libPDFRIP.A.dylib 	pdf_DrawGlyphs 	
4 	libRIP.A.dylib 	rips_DrawGlyphs 	
5 	CoreGraphics 	draw_glyphs 	
6 	CoreGraphics 	CGContextShowGlyphsWithAdvances 	
7 	XUL 	_cairo_quartz_surface_show_glyphs 	gfx/cairo/cairo/src/cairo-quartz-surface.c:2124
8 	XUL 	_cairo_surface_show_text_glyphs 	gfx/cairo/cairo/src/cairo-surface.c:2305
9 	XUL 	_cairo_gstate_show_text_glyphs 	gfx/cairo/cairo/src/cairo-gstate.c:1620
10 	XUL 	_moz_cairo_show_glyphs 	gfx/cairo/cairo/src/cairo.c:3170
11 	XUL 	gfxFont::Draw 	gfx/thebes/src/gfxFont.cpp:325
12 	XUL 	gfxTextRun::DrawGlyphs 	gfx/thebes/src/gfxFont.cpp:1603
13 	XUL 	gfxTextRun::Draw 	gfx/thebes/src/gfxFont.cpp:1813
14 	XUL 	nsTextFrame::DrawText 	layout/generic/nsTextFrameThebes.cpp:4563
15 	XUL 	nsTextFrame::PaintText 	layout/generic/nsTextFrameThebes.cpp:4550
16 	XUL 	nsDisplayText::Paint 	layout/generic/nsTextFrameThebes.cpp:3778
17 	XUL 	nsDisplayList::Paint const 	layout/base/nsDisplayList.cpp:313
18 	XUL 	nsLayoutUtils::PaintFrame 	layout/base/nsLayoutUtils.cpp:1114
19 	XUL 	nsPageFrame::PaintPageContent 	layout/generic/nsPageFrame.cpp:582
20 	XUL 	PaintPageContent 	layout/generic/nsPageFrame.cpp:405
21 	XUL 	nsDisplayGeneric::Paint 	layout/base/nsDisplayList.h:875
22 	XUL 	nsDisplayList::Paint const 	layout/base/nsDisplayList.cpp:313
23 	XUL 	nsLayoutUtils::PaintFrame 	layout/base/nsLayoutUtils.cpp:1114
24 	XUL 	nsSimplePageSequenceFrame::PrintNextPage 	layout/generic/nsSimplePageSequence.cpp:648
25 	XUL 	nsPrintEngine::PrintPage 	layout/printing/nsPrintEngine.cpp:2431
26 	XUL 	nsPagePrintTimer::Notify 	layout/printing/nsPagePrintTimer.cpp:90
27 	XUL 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:423
28 	XUL 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:512
29 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:521
30 	XUL 	NS_ProcessPendingEvents_P 	nsThreadUtils.cpp:189
31 	XUL 	nsBaseAppShell::NativeEventCallback 	widget/src/xpwidgets/nsBaseAppShell.cpp:121
32 	XUL 	nsAppShell::ProcessGeckoEvents 	widget/src/cocoa/nsAppShell.mm:406
33 	CoreFoundation 	__CFRunLoopDoSources0 	
34 	CoreFoundation 	__CFRunLoopRun 	
35 	CoreFoundation 	CFRunLoopRunSpecific 	
36 	CoreFoundation 	CFRunLoopRunInMode 	
37 	HIToolbox 	RunCurrentEventLoopInMode 	
38 	HIToolbox 	ReceiveNextEventCommon 	
39 	HIToolbox 	BlockUntilNextEventMatchingListInMode 	
40 	AppKit 	_DPSNextEvent 	
41 	AppKit 	-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 	
42 	AppKit 	-[NSApplication run] 	
43 	XUL 	nsAppShell::Run 	widget/src/cocoa/nsAppShell.mm:759
44 	XUL 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:193
45 	XUL 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3321
46 	firefox-bin 	main 	browser/app/nsBrowserApp.cpp:156
47 	firefox-bin 	firefox-bin@0x1541 	
48 	firefox-bin 	firefox-bin@0x1468 	
49 		@0x2 	

libPDFRIP.A.dylib 		EBF2754BB509E631B41C1F7061802B4D0 	libPDFRIP.A.dylib
libRIP.A.dylib 		9F0ECE751F0360E4E29C136A27C13F2E0 	libRIP.A.dylib

This is a system framework...
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/

Someone will need to reduce this and file a radar bug.

Comment 4

[Daniel Holbert [:dholbert]]

Confirmed with 3.6b1 and b4, too:
http://crash-stats.mozilla.com/report/index/1a23575e-8ef9-42f9-ac4b-1c9252091214
http://crash-stats.mozilla.com/report/index/97e80ab9-99e1-49d6-a4aa-76b282091214

So, this has been fixed (or worked around) on mozilla-central "recently" -- in the time since 1.9.2 / 3.6 branched off.  I'm guessing that it was probably in a cairo update.

Comment 5

[Daniel Holbert [:dholbert]]

Marcia: if you can reproduce this, could you track down a fix range, in mozilla-central nightlies?

Comment 6

[Marcia Knous [:marcia]]

I will work on Comment 5 - in the meantime adding Steven to the bug since he may able to help me with Comment 3.

Comment 7

[Marcia Knous [:marcia]]

My detective work shows it started working in the 20090927 build, but when looking at the mozilla central checkins it seems difficult to pinpoint what might have fixed it.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20090926 Minefield/3.7a1pre - crash

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20090927 Minefield/3.7a1pre - works

Comment 8

[Daniel Holbert [:dholbert]]

Can you post a pushlog regression range, based on the changeset IDs from "about:buildconfig" in those builds?

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to comment #8)
> Can you post a pushlog regression range
er, s/regression/fix/ :)  URL is of the form:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=XXX&tochange=YYY

Comment 10

[Marcia Knous [:marcia]]

Here is the pushlog regression range: http://tinyurl.com/yb7pwlh

Comment 11

[Daniel Holbert [:dholbert]]

Thanks Marcia! In that range, bug 517877 ("Enable Core Text text back-end by default") looks likely to be responsible for fixing this on trunk, given that the crash here is in system glyph-drawing code.

Marking dependency.

Comment 12

[Jonathan Kew [:jfkthame]]

Does the crash reappear on trunk if you force the use of the ATSUI path? (Go to about:config, set gfx.force_atsui_text to true, and restart the browser.)

Comment 13

[Jonathan Kew [:jfkthame]]

Note that the stack in comment #3 shows a crash within CoreGraphics code that we would ultimately be using to render the glyphs, regardless of whether we're using ATSUI or Core Text for the layout. So I'm not confident that the text back-end switch will necessarily resolve that crash in all cases; we may just be getting lucky in that particular situation.

Comment 14

[Marcia Knous [:marcia]]

Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20090927 Minefield/3.7a1pre, if I change the ATSUI path to true the browser does crash. When I set it back to the default, no crash.

(In reply to comment #12)
> Does the crash reappear on trunk if you force the use of the ATSUI path? (Go to
> about:config, set gfx.force_atsui_text to true, and restart the browser.)

Comment 15

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (reduced)

This significantly-reduced testcase reproduces the same crash for me.

NOTES:
 - The "\", "/", and "." characters are just placeholders.  Generally, I still get a crash regardless of which character I replace these with.
 - The "fi" characters appear important -- I'm guessing this is related to ligatures?
 - There are exactly 100 characters before the "f".  If I add or remove one character, we don't crash.
 - If I remove some characters from after the "f", we don't crash, BUT the text after "fi" gets placed at the wrong position -- on top of "fi". (PDF of output coming up)

Comment 16

[Daniel Holbert [:dholbert]]

Attachment: broken printed output

Here's the result of taking testcase 2, removing the final "." character, and printing to PDF.  Note that the text after "fi" is drawn on top of "fi".

Comment 17

[philippe (part-time)]

Fwiw, I tested the two attached test cases, and NO crashes with Camino 2.0 (Gecko 1.9.0.17pre) and Firefox 3.0.15. Shiretoko builds go down in flames.

Comment 18

[Mats Palmgren (inactive)]

I've filed a bug report to Apple (http://bugreport.apple.com)
Problem id: 7678506

Comment 20

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

In unresymbolized crash reports, this is [@ libPDFRIP.A.dylib@0x181c2 ].

Comment 21

[Wayne Mery (:wsmwk)]

#1 Mac crash for thunderbird 3.0.x

Comment 23

[Wayne Mery (:wsmwk)]

#1 still for Mac


> I've filed a bug report to Apple (http://bugreport.apple.com)
> Problem id: 7678506

any update from apple?  (I can't get to the report)

Comment 24

[Mats Palmgren (inactive)]

Apple says it's fixed in OSX 10.7.
I appears it's low priority for them to fix in 10.6.
I think what we need is repeatable steps to reproduce crashes where the
crash address is not near-zero. Then (hopefully) they will classify it
as a security problem with higher priority.

Comment 25

[Phil Pishioneri]

Crash reporter is claiming my crash

bp-69279901-8e42-4eaf-989a-dfe602100702

matches this bug. However, my gfx.force_atsui_text is false.

Comment 26

[Daniel Holbert [:dholbert]]

(In reply to comment #25)
> Crash reporter is claiming my crash
> bp-69279901-8e42-4eaf-989a-dfe602100702
> matches this bug.

It's just suggesting this bug as a possible match, since it's for a crash in the same function (layout_flush_block).  It sounds like you crashed in a different way from this bug, though -- if your crash is reproducible at all, can you file a new bug on it?

Comment 28

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #26)
> It's just suggesting this bug as a possible match, since it's for a crash in
> the same function (layout_flush_block).  It sounds like you crashed in a
> different way from this bug, though -- if your crash is reproducible at all,
> can you file a new bug on it?

gfx.force_atsui_text set to true is only needed to reproduce these crashes in Gecko>1.9.2.x, since CoreText is the default there.  Crashes with Gecko 1.9.1.x and 1.9.2.x (Firefox 3.5.x and 3.6.x) don't need that pref.

Comment 30

[Wayne Mery (:wsmwk)]

Thunderbird topcrash http://getsatisfaction.com/mozilla_messaging/topics/thunderbird_3_crashes_when_i_try_to_print_an_email

Comment 33

[Sheila Mooney]

This is only appearing in old versions; thunderbird 3.0 and FF 3.5, 3.6. I don't see any crashes in current versions. Resolving as works for me.

Comment 34

[Wayne Mery (:wsmwk)]

agree with tbird findings