Closed Bug 740325 Opened 11 years ago Closed 8 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
Duplicate of this bug: 826187
Duplicate of this bug: 827489
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: 8 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.