Closed Bug 603071 Opened 9 years ago Closed 9 years ago
[D3D10] crash [@ mozilla::layers::Planar
YCb Cr Image D3D10::Allocate Textures() ]
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
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)
Attachment #484230 - Flags: review?(roc) → review+
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.
Attachment #484231 - Flags: review?(roc) → review+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Crash Signature: [@ mozilla::layers::PlanarYCbCrImageD3D10::AllocateTextures() ]
You need to log in before you can comment on or make changes to this bug.