Closed Bug 740325 Opened 13 years ago Closed 11 years ago

crash in _cairo_surface_snapshot_copy_on_write while printing

Categories

(Core :: Graphics, defect)

15 Branch
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla31
Tracking Status
firefox18 --- wontfix
firefox19 --- unaffected
firefox30 --- verified
firefox31 --- verified
firefox-esr17 --- wontfix

People

(Reporter: scoobidiver, Assigned: bas.schouten)

References

Details

(Keywords: crash, reproducible, topcrash-win, Whiteboard: [native-crash])

Crash Data

It first appeared in 14.0a1/20120323. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5c13fce74f83&tochange=ab2ff3b5611f Signature memcpy | _cairo_surface_snapshot_copy_on_write More Reports Search UUID b37ab0b4-bcbf-4244-98a4-203be2120329 Date Processed 2012-03-29 08:08:18 Uptime 34 Last Crash 37 seconds before submission Install Age 3.6 minutes since version was first installed. Install Time 2012-03-29 08:04:12 Product Firefox Version 14.0a1 Build ID 20120328031211 Release Channel nightly OS Windows NT OS Version 6.1.7601 Service Pack 1 Build Architecture amd64 Build Architecture Info family 15 model 4 stepping 3 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x11100000 App Notes AdapterVendorID: 0x8086, AdapterDeviceID: 0x2772, AdapterSubsysID: 00871025, AdapterDriverVersion: 8.15.10.1930 D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- EMCheckCompatibility True Total Virtual Memory 8796092891136 Available Virtual Memory 8795739688960 System Memory Use Percentage 50 Available Page File 4861100032 Available Physical Memory 1718554624 Frame Module Signature Source 0 msvcr100.dll memcpy f:\\dd\\vctools\\crt_bld\\SELF_64_amd64\\crt\\src\\amd64\\memcpy.asm:224 1 xul.dll _cairo_surface_snapshot_copy_on_write gfx/cairo/cairo/src/cairo-surface-snapshot.c:140 2 xul.dll cairo_path_fixed_init_copy gfx/cairo/cairo/src/cairo-path-fixed.c:143 3 xul.dll cairo_surface_detach_snapshot gfx/cairo/cairo/src/cairo-surface.c:331 4 xul.dll gfxContext::Mask gfx/thebes/gfxContext.cpp:1435 5 xul.dll moz_cairo_surface_flush gfx/cairo/cairo/src/cairo-surface.c:1114 6 xul.dll moz_cairo_destroy gfx/cairo/cairo/src/cairo.c:454 7 xul.dll gfxContext::~gfxContext gfx/thebes/gfxContext.cpp:137 8 KERNELBASE.dll VirtualFree 9 xul.dll gfxContext::`scalar deleting destructor' 10 xul.dll gfxContext::Release obj-firefox/dist/include/gfxContext.h:74 11 xul.dll nsRefPtr<gfxContext>::~nsRefPtr<gfxContext> obj-firefox/dist/include/nsAutoPtr.h:908 12 xul.dll nsCSSRendering::PaintBoxShadowOuter layout/base/nsCSSRendering.cpp:1283 13 xul.dll nsLayoutUtils::GetSnappedBaselineY layout/base/nsLayoutUtils.cpp:3037 14 xul.dll cairo_path_fixed_line_to gfx/cairo/cairo/src/cairo-path-fixed.c:548 More reports at: https://crash-stats.mozilla.com/report/list?signature=memcpy+|+_cairo_surface_snapshot_copy_on_write
Depends on: 746896
OS: Windows 7 → All
Hardware: x86_64 → All
Whiteboard: [native-crash]
Assignee: nobody → bas.schouten
No longer depends on: 746896
Depends on: 746896
This stack doesn't make a lot of sense sadly. I'm not sure yet what's going on there.
Here is a recent stack trace: Signature memcpy | _cairo_surface_snapshot_copy_on_write More Reports Search UUID 33e34f1a-2061-4e6e-9862-829d92120906 Date Processed 2012-09-06 20:17:44 Uptime 785 Last Crash 1.4 weeks before submission Install Age 8.2 hours since version was first installed. Install Time 2012-09-06 12:04:07 Product Firefox Version 17.0a2 Build ID 20120905042008 Release Channel aurora OS Windows NT OS Version 5.1.2600 Service Pack 3 Build Architecture x86 Build Architecture Info GenuineIntel family 6 model 28 stepping 2 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x199ffffc App Notes AdapterVendorID: 0x8086, AdapterDeviceID: 0x27ae, AdapterSubsysID: 00000000, AdapterDriverVersion: 6.14.10.4926 D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- EMCheckCompatibility True Adapter Vendor ID 0x8086 Adapter Device ID 0x27ae Total Virtual Memory 2147352576 Available Virtual Memory 1698037760 System Memory Use Percentage 74 Available Page File 1673277440 Available Physical Memory 268214272 Frame Module Signature Source 0 msvcr100.dll memcpy f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm:404 1 gkmedias.dll _cairo_surface_snapshot_copy_on_write gfx/cairo/cairo/src/cairo-surface-snapshot.c:140 2 gkmedias.dll cairo_surface_detach_snapshot gfx/cairo/cairo/src/cairo-surface.c:331 3 gkmedias.dll _moz_cairo_destroy gfx/cairo/cairo/src/cairo.c:454 4 gkmedias.dll gkmedias.dll@0x1728f 5 xul.dll gfxContext::~gfxContext gfx/thebes/gfxContext.cpp:112 6 xul.dll nsCSSRendering::PaintBoxShadowOuter layout/base/nsCSSRendering.cpp:1157 7 xul.dll nsDisplayBoxShadowOuter::Paint layout/base/nsDisplayList.cpp:2100 8 xul.dll mozilla::FrameLayerBuilder::DrawThebesLayer layout/base/FrameLayerBuilder.cpp:2862 9 xul.dll mozilla::gfx::BaseRect<double,gfxRect,gfxPoint,gfxSize,gfxMargin>::RoundOut obj-firefox/dist/include/mozilla/gfx/BaseRect.h:348 10 @0xc5e369f
Summary: crash in gfxContext::Mask @ memcpy | _cairo_surface_snapshot_copy_on_write → crash in nsCSSRendering::PaintBoxShadowOuter @ memcpy | _cairo_surface_snapshot_copy_on_write
I added a related crash signature which is #46 top browser crasher in 15.0.1, #117 in 16.0b3, and #76 in 17.0a2. For both signatures, almost all comments are about printing which is confirmed by DLL correlations in 15.0.1: _VEC_memcpy | _cairo_surface_snapshot_copy_on_write|EXCEPTION_ACCESS_VIOLATION_READ (241 crashes) 58% (140/241) vs. 1% (934/157345) prnfldr.dll More reports at: https://crash-stats.mozilla.com/report/list?signature=_VEC_memcpy+|+_cairo_surface_snapshot_copy_on_write
Crash Signature: [@ memcpy | _cairo_surface_snapshot_copy_on_write] → [@ memcpy | _cairo_surface_snapshot_copy_on_write] [@ _VEC_memcpy | _cairo_surface_snapshot_copy_on_write]
Keywords: regression
Summary: crash in nsCSSRendering::PaintBoxShadowOuter @ memcpy | _cairo_surface_snapshot_copy_on_write → crash in _cairo_surface_snapshot_copy_on_write while priting
Version: 14 Branch → 15 Branch
It's #33 top browser crasher in 18.0.1 and #4 in 17.0.2esr which is high for a print-only issue. It seems to be fixed in 19.0 and above. If someone knows which patch has fixed it, it should be uplifted to ESR.
Just got this crash when clicking to exit print preview right after submitting a print job. bp-00df4053-5ecf-4e4f-83b6-3a1a12140404
I know this is an old bug, but this spiked to #1 on 30 and #2+#3 on 31 in the last few days, and comment #9 here sounds like it's still printing so I'll reuse the existing bug report here.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #10) > I know this is an old bug, but this spiked to #1 on 30 and #2+#3 on 31 in > the last few days, and comment #9 here sounds like it's still printing so > I'll reuse the existing bug report here. Looking at the explosiveness report this was all zeros until 2014-04-04 where it spiked. Here is the pushlog for the spike: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ac6cbaa47f34&tochange=6c924a018540
Keywords: topcrash-win
I can repro this using an m-c built yesterday. Win7, default graphics prefs. 1. Go to mapquest.com. No need to search or anything, the front page will work. 2. Print (fake printer like PDF is fine) 3. Close the browser. 4. Crash during close. I've saved a full-heap dump if anyone is interested.
Milan, can we get some gfx eyes on this reproducible topcrash? It's strange that this started April 4 on both Nightly and Aurora. I don't see any intersection in the pushlogs. Maybe it's related to some pref that's only enabled on those channels?
Flags: needinfo?(milan)
msvcr120!TrailDownVec gkmedias!_cairo_surface_snapshot_copy_on_write gkmedias!cairo_surface_detach_snapshot gkmedias!cairo_surface_detach_snapshots gkmedias!_moz_cairo_surface_finish gkmedias!_moz_cairo_surface_destroy xul!gfxASurface::Release xul!imgFrame::~imgFrame xul!nsAutoPtr<imgFrame>::~nsAutoPtr<imgFrame> xul!nsTArray_Impl<mozilla::image::FrameDataPair,nsTArrayInfallibleAllocator>::DestructRange xul!nsTArray_Impl<mozilla::image::FrameDataPair,nsTArrayInfallibleAllocator>::RemoveElementsAt xul!mozilla::image::FrameSequence::ClearFrames xul!mozilla::image::FrameSequence::~FrameSequence xul!mozilla::image::FrameSequence::Release xul!nsRefPtr<mozilla::image::FrameSequence>::assign_with_AddRef xul!mozilla::image::FrameBlender::ClearFrames xul!mozilla::image::RasterImage::Discard xul!mozilla::image::DiscardTracker::DiscardAll xul!mozilla::image::DiscardTracker::Shutdown xul!nsComponentManagerImpl::KnownModule::`scalar deleting destructor' xul!nsTArray_Impl<nsAutoPtr<nsComponentManagerImpl::KnownModule>,nsTArrayInfallibleAllocator>::RemoveElementsAt xul!nsComponentManagerImpl::Shutdown xul!mozilla::ShutdownXPCOM xul!ScopedXPCOMStartup::~ScopedXPCOMStartup xul!ScopedXPCOMStartup::`scalar deleting destructor' xul!XREMain::XRE_main xul!XRE_main firefox!do_main firefox!NS_internal_main firefox!wmain firefox!__tmainCRTStartup kernel32!BaseThreadInitThunk ntdll!__RtlUserThreadStart ntdll!_RtlUserThreadStart
The timing is not quite right, but Bas, given that this is PDF printing, maybe your recent changes tickled the old bug?
Flags: needinfo?(milan) → needinfo?(bas)
Keywords: reproducible
I tried getting a WinDbg stack trace but would get an error every time I tried to print while debugging. Is there something in Firefox that should be preventing printing while debugging?
I can no longer reproduce this on m-i built today or m-c built last night. Maybe it was fixed or maybe it's intermittent or code-layout dependent. I'll be interested to see the numbers from the next Nightly. (In reply to IU from comment #17) > Is there something in Firefox that should be preventing printing while debugging? I haven't had any problems.
I don't know the code to say whether it's truly fixed, but this no longer reproduces on m-c as of: https://hg.mozilla.org/mozilla-central/rev/7248b992c6b2 Bug 991767 - Use Moz2D for printing surfaces. r=roc No hits on nightly after 0407. Still on Aurora though so maybe that patch should be uplifted.
(In reply to Milan Sreckovic [:milan] from comment #16) > The timing is not quite right, but Bas, given that this is PDF printing, > maybe your recent changes tickled the old bug? It might be caused by some of jwatt's stuff? I didn't do much recently to affect this. However it looks like his more recent moz2d-ification work -also- fixed this :). So I'm not 100% sure what to do :). I'm not sure how easy it would be to uplift the patch to bug 991767 to Aurora (i.e. what other dependencies it has)
Flags: needinfo?(bas)
(In reply to David Major [:dmajor] (UTC+12) from comment #19) > https://hg.mozilla.org/mozilla-central/rev/7248b992c6b2 > Bug 991767 - Use Moz2D for printing surfaces. r=roc That Matt Woodrow's patch. Matt, how easy would it be to get that to Aurora? (In reply to Bas Schouten (:bas.schouten) from comment #20) > It might be caused by some of jwatt's stuff? jwatt, what do you think? If we can't uplift the above patch, what can we do here?
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(jwatt)
My patches over the last few weeks have built on each other to a large extent. Having a go at uplifting Matt's simple patch from bug 991767 would be the first thing to try, I'd think. If that doesn't work then we can spend time digging into alternatives.
Flags: needinfo?(jwatt)
I've requested uplift approval for bug 991767.
Flags: needinfo?(matt.woodrow)
Summary: crash in _cairo_surface_snapshot_copy_on_write while priting → crash in _cairo_surface_snapshot_copy_on_write while printing
It looks like bug 991767 may have helped here. There is still significant volume but all crashes seem to be with build 20140407030203 or earlier. It also seems to have dropped nearly 5% in combined signatures.
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #24) > It looks like bug 991767 may have helped here. There is still significant > volume but all crashes seem to be with build 20140407030203 or earlier. It > also seems to have dropped nearly 5% in combined signatures. If it's all build IDs before bug 991767 landed, then I'd see that as pretty firm confirmation that it did fix the one here as well. :)
Uplift of bug 991767 seems to have fixed this on Fx30. This was by far the top crasher on Aurora (Fx30). Will be good to see this go away.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Depends on: 991767
Target Milestone: --- → mozilla31
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.