[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

VERIFIED WORKSFORME

Status

()

Core
Printing: Output
--
critical
VERIFIED WORKSFORME
9 years ago
7 years ago

People

(Reporter: Dan Leehr, Unassigned)

Tracking

(4 keywords)

Trunk
mozilla1.9.3a5
x86
Mac OS X
crash, regression, testcase, topcrash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [apple radar:7678506][tb31wants][gs], crash signature, URL)

Attachments

(3 attachments)

(Reporter)

Description

9 years ago
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
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → 1.9.1 Branch
Created attachment 417521 [details]
testcase 1 (original)

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

Comment 3

9 years ago
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.
Keywords: crash
Summary: Attempting to print or preview certain pages will crash firefox on Mac OS X 10.6 Snow Leopard → Attempting to print or preview certain pages will crash firefox on Mac OS X 10.6 Snow Leopard [@ layout_flush_block]
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.
Version: 1.9.1 Branch → 1.9.2 Branch
Marcia: if you can reproduce this, could you track down a fix range, in mozilla-central nightlies?
I will work on Comment 5 - in the meantime adding Steven to the bug since he may able to help me with Comment 3.
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
Can you post a pushlog regression range, based on the changeset IDs from "about:buildconfig" in those builds?
(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
Here is the pushlog regression range: http://tinyurl.com/yb7pwlh
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.
Depends on: 517877
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.)
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.
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.)
Summary: Attempting to print or preview certain pages will crash firefox on Mac OS X 10.6 Snow Leopard [@ layout_flush_block] → Print crash on Mac OS X 10.6 Snow Leopard [@ layout_flush_block], with gfx.force_atsui_text turned on
Version: 1.9.2 Branch → Trunk
Created attachment 417595 [details]
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)
Created attachment 417596 [details]
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".
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.
Keywords: regression, testcase

Updated

9 years ago
Blocks: 529165
I've filed a bug report to Apple (http://bugreport.apple.com)
Problem id: 7678506
Whiteboard: [apple radar:7678506]
In unresymbolized crash reports, this is [@ libPDFRIP.A.dylib@0x181c2 ].
Summary: Print crash on Mac OS X 10.6 Snow Leopard [@ layout_flush_block], with gfx.force_atsui_text turned on → Print crash on Mac OS X 10.6 Snow Leopard [@ layout_flush_block] or [@ libPDFRIP.A.dylib@0x181c2 ], with gfx.force_atsui_text turned on

Comment 21

8 years ago
#1 Mac crash for thunderbird 3.0.x

Updated

8 years ago
Duplicate of this bug: 547618

Comment 23

8 years ago
#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)
Whiteboard: [apple radar:7678506] → [apple radar:7678506][tb31wants]
Target Milestone: --- → mozilla1.9.3a5
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

8 years ago
Crash reporter is claiming my crash

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

matches this bug. However, my gfx.force_atsui_text is false.
(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?

Updated

8 years ago
Duplicate of this bug: 590038
(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.
Summary: Print crash on Mac OS X 10.6 Snow Leopard [@ layout_flush_block] or [@ libPDFRIP.A.dylib@0x181c2 ], with gfx.force_atsui_text turned on → [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

Comment 30

8 years ago
Thunderbird topcrash http://getsatisfaction.com/mozilla_messaging/topics/thunderbird_3_crashes_when_i_try_to_print_an_email
Keywords: topcrash
Whiteboard: [apple radar:7678506][tb31wants] → [apple radar:7678506][tb31wants][gs]

Updated

7 years ago
Duplicate of this bug: 642915

Updated

7 years ago
Duplicate of this bug: 557639
(Assignee)

Updated

7 years ago
Crash Signature: [@ layout_flush_block] [@ libPDFRIP.A.dylib@0x181c2 ]

Comment 33

7 years ago
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.
Status: NEW → RESOLVED
Crash Signature: [@ layout_flush_block] [@ libPDFRIP.A.dylib@0x181c2 ] → [@ layout_flush_block] [@ libPDFRIP.A.dylib@0x181c2 ]
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME

Comment 34

7 years ago
agree with tbird findings
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.