Closed Bug 611597 Opened 14 years ago Closed 11 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: 14 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: 14 years ago → 14 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: 14 years ago → 11 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: