User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:22.214.171.124) Gecko/20091102 Firefox/3.5.5 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:126.96.36.199) 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:188.8.131.52) 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.
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.
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.
Marcia: if you can reproduce this, could you track down a fix range, in mozilla-central nightlies?
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 184.108.40.206pre) and Firefox 3.0.15. Shiretoko builds go down in flames.
I've filed a bug report to Apple (http://bugreport.apple.com) Problem id: 7678506
Whiteboard: [apple radar:7678506]
Duplicate of this bug: 547889
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
#1 Mac crash for thunderbird 3.0.x
#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.
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?
(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
Duplicate of this bug: 586870
Thunderbird topcrash http://getsatisfaction.com/mozilla_messaging/topics/thunderbird_3_crashes_when_i_try_to_print_an_email
Whiteboard: [apple radar:7678506][tb31wants] → [apple radar:7678506][tb31wants][gs]
Crash Signature: [@ layout_flush_block] [@ libPDFRIP.A.dylib@0x181c2 ]
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
agree with tbird findings
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.