740325 - crash in _cairo_surface_snapshot_copy_on_write while printing

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Scoobidiver (away)]

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

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

A fennec stack:
https://crash-stats.mozilla.com/report/index/94f07f99-7704-4d9b-a777-c68fb2120513

Comment 2

[Bas Schouten (:bas.schouten)]

This stack doesn't make a lot of sense sadly. I'm not sure yet what's going on there.

Comment 3

[Scoobidiver (away)]

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

Comment 4

[Scoobidiver (away)]

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

Comment 5

[smarttemplate4]

yes same Problem for me
bp-2f84e53a-4d11-4562-8c49-a7d182130103
bp-944752f9-61af-42da-a35e-20da52130103
bp-fadb4ad1-724e-4d93-b824-2dd902130103
bp-bd09533d-35e6-460f-a6b9-daf602130103
see additional
https://bugzilla.mozilla.org/show_bug.cgi?id=826187

Comment 8

[Scoobidiver (away)]

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.

Comment 9

[IU]

Just got this crash when clicking to exit print preview right after submitting a print job.

bp-00df4053-5ecf-4e4f-83b6-3a1a12140404

Comment 10

[Robert Kaiser]

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.

Comment 11

[u279076]

(In reply to Robert Kaiser (:[e-mail]) 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

Comment 12

[u279076]

Pushlog for Aurora:
https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=b728a2085cba&tochange=3186bbc50050

Comment 13

[(Away)]

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.

Comment 14

[(Away)]

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?

Comment 15

[(Away)]

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

Comment 16

[Milan Sreckovic [:milan] (needinfo for best results)]

The timing is not quite right, but Bas, given that this is PDF printing, maybe your recent changes tickled the old bug?

Comment 17

[IU]

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?

Comment 18

[(Away)]

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.

Comment 19

[(Away)]

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.

Comment 20

[Bas Schouten (:bas.schouten)]

(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)

Comment 21

[Robert Kaiser]

(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?

Comment 22

[Jonathan Watt [: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.

Comment 23

[Matt Woodrow (:mattwoodrow)]

I've requested uplift approval for bug 991767.

Comment 24

[u279076]

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.

Comment 25

[Robert Kaiser]

(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. :)

Comment 26

[Tracy Walker [:tracy]]

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.