Closed Bug 603071 Opened 9 years ago Closed 9 years ago

[D3D10] crash [@ mozilla::layers::PlanarYCbCrImageD3D10::AllocateTextures() ]

Categories

(Core :: Graphics, defect, critical)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta8+

People

(Reporter: scoobidiver, Assigned: bas.schouten)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(2 files)

Build: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101008 Firefox/4.0b8pre

This is a new crash signature. Crashes first appeared in b8pre/20101007 build.
It is #5 top crasher in b8pre/20101008 build.

Signature	mozilla::layers::PlanarYCbCrImageD3D10::AllocateTextures()
UUID	fb529673-9f3a-4c1c-9f26-2c6292101009
Time 	2010-10-09 03:43:52.167111
Uptime	3097
Last Crash	4460 seconds (1.2 hours) before submission
Install Age	77952 seconds (21.7 hours) since version was first installed.
Product	Firefox
Version	4.0b8pre
Build ID	20101008041525
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 23 stepping 6
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0xc35e7f
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 064c

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	mozilla::layers::PlanarYCbCrImageD3D10::AllocateTextures 	gfx/layers/d3d10/ImageLayerD3D10.cpp:322
1 	xul.dll 	mozilla::layers::PlanarYCbCrImageD3D10::SetData 	gfx/layers/d3d10/ImageLayerD3D10.cpp:288

The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dee1e01fd8ed&tochange=5bb4f093a50b

More reports at:
http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=mozilla%3A%3Alayers%3A%3APlanarYCbCrImageD3D10%3A%3AAllocateTextures%28%29
blocking2.0: --- → ?
Happens with lots of HTML5/WebM videos open.
Top 5? I wouldn't have expected that many people to switch D3D10 layers on.
> Top 5? I wouldn't have expected that many people to switch D3D10 layers on.
According to the crash stats, there are four different users.
Doesn't seem to happen anymore, at least with HTML5 Youtube.
How weird, I didn't do anything!
Assignee: nobody → bas.schouten
blocking2.0: ? → beta8+
I'm taking this opportunity to fix ownership, there's a small bug here where Destroy wasn't implemented to clear all references from its layer tree like it does for other layer manager. This should fix this.
Attachment #484230 - Flags: review?(roc)
PlanarYCbCrImageD3D10 should hold a reference to the D3D10 device since it needs to have this device around when SetData is called. Not storing the manager but rather the device is the best solution here.
Attachment #484231 - Flags: review?(roc)
Why is PlanarYCbCrImageD3D10 calling AllocateTextures in SetData? Can't you defer the AllocateTextures until we paint? That's what we do in ImageLayerOGL, and it means AllocateTextures only happens on the main thread.
(I can see how calling AllocateTextures off the main thread might let you avoid a copy, but you're not doing that.)
(In reply to comment #8)
> Why is PlanarYCbCrImageD3D10 calling AllocateTextures in SetData? Can't you
> defer the AllocateTextures until we paint? That's what we do in ImageLayerOGL,
> and it means AllocateTextures only happens on the main thread.

Texture allocation is fairly CPU intensive, also these function may create an additional internal copy, this copy is now executed on a separate thread. I believe these 3 calls constitute a fairly significant amount of work, so I personally think it's worth it to do it on the decoding thread.

Eventually as you say, it might also help us avoid the copy.
http://hg.mozilla.org/mozilla-central/rev/48e881871600
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Depends on: 606411
Crash Signature: [@ mozilla::layers::PlanarYCbCrImageD3D10::AllocateTextures() ]
You need to log in before you can comment on or make changes to this bug.