Closed Bug 611597 Opened 15 years ago Closed 12 years ago

crash [@ mozilla::layers::DeviceManagerD3D9::IsD3D9Ex() ] or [@ mozilla::layers::CairoImageD3D9::GetOrCreateTexture() ]

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: scoobidiver, Assigned: bas.schouten)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

Deal with changing layer managers in D3D9 layers
12.07 KB, patch
Details | Diff | Splinter Review
Build: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101111 Firefox/4.0b8pre It is a new crash signature. Crashes first appeared with this build. It is #6 top crasher in this build: 70 crashes/buildday. One comment says: "gmail, tried to forward a message". Signature mozilla::layers::DeviceManagerD3D9::IsD3D9Ex() UUID 52743ae6-e348-428c-b49b-0e6472101112 Time 2010-11-12 01:25:37.898396 Uptime 3000 Last Crash 3078 seconds (51.3 minutes) before submission Install Age 37416 seconds (10.4 hours) since version was first installed. Product Firefox Version 4.0b8pre Build ID 20101111042449 Branch 2.0 OS Windows NT OS Version 5.1.2600 Service Pack 3 CPU x86 CPU Info GenuineIntel family 6 model 15 stepping 2 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x29786982 App Notes AdapterVendorID: 1002, AdapterDeviceID: 94c3 Frame Module Signature [Expand] Source 0 xul.dll mozilla::layers::DeviceManagerD3D9::IsD3D9Ex obj-firefox/dist/include/DeviceManagerD3D9.h:138 1 xul.dll mozilla::layers::CairoImageD3D9::SetData gfx/layers/d3d9/ImageLayerD3D9.cpp:466 2 xul.dll nsPluginInstanceOwner::SetCurrentImage layout/generic/nsObjectFrame.cpp:1726 3 xul.dll nsPluginInstanceOwner::InvalidateRect layout/generic/nsObjectFrame.cpp:3097 4 xul.dll nsNPAPIPluginInstance::InvalidateRect modules/plugin/base/src/nsNPAPIPluginInstance.cpp:1134 5 xul.dll mozilla::plugins::parent::_invalidaterect modules/plugin/base/src/nsNPAPIPlugin.cpp:1264 6 xul.dll mozilla::plugins::PluginInstanceParent::RecvNPN_InvalidateRect dom/plugins/PluginInstanceParent.cpp:472 7 xul.dll mozilla::plugins::PluginInstanceParent::RecvShow dom/plugins/PluginInstanceParent.cpp:522 8 xul.dll mozilla::plugins::PPluginInstanceParent::OnMessageReceived obj-firefox/ipc/ipdl/PPluginInstanceParent.cpp:910 9 xul.dll mozilla::plugins::PPluginModuleParent::OnMessageReceived obj-firefox/ipc/ipdl/PPluginModuleParent.cpp:570 10 xul.dll mozilla::ipc::SyncChannel::OnDispatchMessage ipc/glue/SyncChannel.cpp:169 11 xul.dll mozilla::ipc::RPCChannel::OnMaybeDequeueOne ipc/glue/RPCChannel.cpp:436 12 xul.dll MessageLoop::RunTask ipc/chromium/src/base/message_loop.cc:343 13 xul.dll MessageLoop::DeferOrRunPendingTask ipc/chromium/src/base/message_loop.cc:351 14 xul.dll MessageLoop::DoWork ipc/chromium/src/base/message_loop.cc:451 15 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:114 16 xul.dll xul.dll@0xb0aac3 17 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:202 18 xul.dll _SEH_epilog4 19 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:176 20 xul.dll nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:181 21 xul.dll xul.dll@0xb0aac3 22 xul.dll nsAppShell::Run widget/src/windows/nsAppShell.cpp:243 23 nss3.dll pkix_pl_CertNameConstraints_ToString security/nss/lib/libpkix/pkix_pl_nss/pki/pkix_pl_nameconstraints.c:539 The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=df1d1ff6b489&tochange=0f17e5f1eb01 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%3ADeviceManagerD3D9%3A%3AIsD3D9Ex%28%29
blocking2.0: --- → ?
Assignee: nobody → benjamin
blocking2.0: ? → beta8+
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
It is #1 top crasher in 4.0b8pre/20101120 build.
Happens on both NVIDIA and ATI, although there's a wide majority of NVIDIA (where it also isn't concentrated on one GPU family). NVIDIA example: http://crash-stats.mozilla.com/report/index/fb60f225-73be-43ea-957d-289882101121 ATI example: http://crash-stats.mozilla.com/report/index/66bd624e-30dd-4b9f-b94f-430c02101121
We are crashing in CairoImageD3D9::SetData() when doing: mManager->deviceManager()->IsD3D9Ex() the methods called here are just trivial inline non-virtual accessors, so this amounts to: mManager->mDeviceManager->mDeviceEx Thus the only way that this can crash, is that either mManager or mDeviceManager pointers are bad. Are there any known steps to reproduce? One should run them in a debugger, having set watchpoints on these pointers.
CC'ing Bas. Does my comment 4 ring a bell?
Sounds like we're switching layer managers (probably mManager is dead), there's a similar bug I commented on earlier. But in that case, we were in BuildLayer and could detect that the layer manager was changed. In this bug, I don't know how we'd know that since we're not in BuildLayer.
(In reply to comment #6) > Sounds like we're switching layer managers (probably mManager is dead), there's > a similar bug I commented on earlier. But in that case, we were in BuildLayer > and could detect that the layer manager was changed. In this bug, I don't know > how we'd know that since we're not in BuildLayer. If we detect and switch containers in BuildLayer. We'll never hit this issue (i.e. we won't switch layer managers between BuildLayer and the EndTransaction where this is executed.
The question is why we're switching layer managers though! A display lock shouldn't do that, I'm investigating this.
This code isn't executing between BuildLayer and EndTransaction, I don't think...
So, the fact we're switching LayerManagers seems to be a bug (not one with serious consequences by itself, but I'll still try to fix it). I'm not 100% sure what to do with this being asynchronous to transactions. I've never considered the possibility of SetData occurring outside of a transaction. I need to think about this some more. I've got a patch which fixes all crashes I could reproduce though. I'll put it up in a minute. It will stop drawing plugins when a switch is made from a non-D3D9 layer manager to a D3D9 one though.
This patch will take care of all the needed work to deal with changing layer managers for ImageLayerD3D9::RenderLayer. It moves stuff around a bit to ensure it always behaves predictably.
Attachment #492314 - Flags: review?(vladimir)
Assignee: benjamin → bas.schouten
does this need to be "un-duped" to take the patch? its currently the #1 top crash on trunk so getting a fix before beta 8 goes out would be good.
(In reply to comment #13) > does this need to be "un-duped" to take the patch? its currently the #1 top > crash on trunk so getting a fix before beta 8 goes out would be good. This bug is not a dupe at the moment, although it's similar to many other issues like this. I should note however that this is not the 'true' solution although it's good enough for most cases (except some!). We need the proper patch on the async plugin rendering side.
Note that I currently know of one bug where we don't check for a changed layer manager in BuildLayer, that will be taken care of in bug 613744. That won't really change this bug at all, though.
Attachment #492314 - Flags: review?(vladimir) → review?(jmuizelaar)
Summary: crash [@ mozilla::layers::DeviceManagerD3D9::IsD3D9Ex() ] → crash [@ mozilla::layers::DeviceManagerD3D9::IsD3D9Ex() ] or [@ mozilla::layers::CairoImageD3D9::GetOrCreateTexture() ]
If we magically don't get a crash when accessing IsD3D9Ex(), we can get an equivalent crash when we actually go to use the manager, which accounts for both crashes.
Depends on: 614111
Bug 614111 will drastically reduce the amount of LayerManager recreations on Windows XP and should also have a positive effect on the frequency of this crasher.
lets get the nomination on that one bumped to beta8 blocking then.
blocking2.0: beta8+ → beta9+
We should still try get this patch into Beta 8, for one it prevents crashing when people disable hardware acceleration while having a site open with plugins.
There is no crash in today's nighlty. So this bug is a dupe of bug 614111.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
No longer depends on: 614111
Resolution: --- → DUPLICATE
I think we still need to get this patch reviewed and landed, as Bas mentioned in comment 20. That seems like a rarer crash, but it could still happen.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Depends on: 614111
Still top b8pre crasher as of today. sample crash report from yesterday: http://crash-stats.mozilla.com/report/index/91604286-fbfe-48b1-9a7c-d32982101128
> sample crash report from yesterday: > http://crash-stats.mozilla.com/report/index/91604286-fbfe-48b1-9a7c-d32982101128 Build ID: 20101123045657! No crashes in the last 2 nightlies.
Keywords: topcrash
Comment on attachment 492314 [details] [diff] [review] Deal with changing layer managers in D3D9 layers It would be nice to have a test for this scenario
(In reply to comment #26) > Comment on attachment 492314 [details] [diff] [review] > Deal with changing layer managers in D3D9 layers > > It would be nice to have a test for this scenario This is a very complicated endeavor as far as I can see, it would require C++ code to 'fake' layer manager transitions, and then it would require us to have a playing video at the same time. Personally not something I believe we should sink a lot of time in for FF4. Although I certainly see the value, if someone has an idea to do this more 'easily' I'd love to hear it.
This is very low-volume.
blocking2.0: beta9+ → betaN+
Yes, reinstalling drivers will still do this. We're working on an alternative to the patch on this bug.
blocking2.0: betaN+ → -
Attachment #492314 - Flags: review?(jmuizelaar)
Crash Signature: [@ mozilla::layers::DeviceManagerD3D9::IsD3D9Ex() ] [@ mozilla::layers::CairoImageD3D9::GetOrCreateTexture() ]
The signature mozilla::layers::DeviceManagerD3D9::IsD3D9Ex() doesn't appear on any version in the past 4 weeks. The other one, mozilla::layers::CairoImageD3D9::GetOrCreateTexture(), shows up but in very low volume. Only 1 in the last 4 weeks.
Crash Signature: [@ mozilla::layers::DeviceManagerD3D9::IsD3D9Ex() ] [@ mozilla::layers::CairoImageD3D9::GetOrCreateTexture() ] → [@ mozilla::layers::DeviceManagerD3D9::IsD3D9Ex() ] [@ mozilla::layers::CairoImageD3D9::GetOrCreateTexture() ]
There have been one crash in 22.0 and two in 23.0 Beta for the last four weeks so no need to track in Bugzilla.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: