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 #4 mega top crasher in this build: 200 crashes/buildday. It can be related to bug 611593. Signature mozilla::layers::CairoImageD3D9::SetData(mozilla::layers::CairoImage::Data const&) UUID cb670a52-0d67-4f19-b185-80e322101112 Time 2010-11-12 01:28:56.970483 Uptime 3318 Last Crash 3329 seconds (55.5 minutes) before submission Install Age 69522 seconds (19.3 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 10 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x0 User Comments App Notes AdapterVendorID: 10de, AdapterDeviceID: 042b Processor Notes EMCheckCompatibility False Crashing Thread Frame Module Signature [Expand] Source 0 xul.dll mozilla::layers::CairoImageD3D9::SetData gfx/layers/d3d9/ImageLayerD3D9.cpp:472 1 xul.dll nsPluginInstanceOwner::SetCurrentImage layout/generic/nsObjectFrame.cpp:1726 2 xul.dll nsPluginInstanceOwner::InvalidateRect layout/generic/nsObjectFrame.cpp:3097 3 xul.dll nsNPAPIPluginInstance::InvalidateRect modules/plugin/base/src/nsNPAPIPluginInstance.cpp:1134 4 xul.dll mozilla::plugins::parent::_invalidaterect modules/plugin/base/src/nsNPAPIPlugin.cpp:1264 5 xul.dll mozilla::plugins::PluginInstanceParent::RecvNPN_InvalidateRect dom/plugins/PluginInstanceParent.cpp:472 6 xul.dll mozilla::plugins::PluginInstanceParent::RecvShow dom/plugins/PluginInstanceParent.cpp:522 7 xul.dll mozilla::plugins::PPluginInstanceParent::OnMessageReceived obj-firefox/ipc/ipdl/PPluginInstanceParent.cpp:910 8 xul.dll mozilla::plugins::PPluginModuleParent::OnMessageReceived obj-firefox/ipc/ipdl/PPluginModuleParent.cpp:570 9 xul.dll mozilla::ipc::SyncChannel::OnDispatchMessage ipc/glue/SyncChannel.cpp:169 10 xul.dll mozilla::ipc::RPCChannel::OnMaybeDequeueOne ipc/glue/RPCChannel.cpp:436 11 xul.dll MessageLoop::RunTask ipc/chromium/src/base/message_loop.cc:343 12 xul.dll MessageLoop::DeferOrRunPendingTask ipc/chromium/src/base/message_loop.cc:351 13 xul.dll MessageLoop::DoWork ipc/chromium/src/base/message_loop.cc:451 14 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:114 15 xul.dll xul.dll@0xb0aac3 16 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:202 17 xul.dll _SEH_epilog4 18 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:176 19 xul.dll nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:181 20 xul.dll xul.dll@0xb0aac3 21 xul.dll nsAppShell::Run widget/src/windows/nsAppShell.cpp:243 22 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%3ACairoImageD3D9%3A%3ASetData%28mozilla%3A%3Alayers%3A%3ACairoImage%3A%3AData%20const%26%29

I got this crash: http://crash-stats.mozilla.com/report/index/bp-9dfa6e5d-1cfe-46c9-a5d1-e7b282101116 http://crash-stats.mozilla.com/report/index/bp-fc070fce-b1e7-41fa-a0ec-aadaa2101116 Steps to reproduce: 1. Login to gmail 2. Lock your computer (win + L) 3. Open a conversation, click "reply" 4. Reliable crash

It became #1 top crasher in 4.0b8pre/20101116 build because of the fixing of others bugs. Some comments say: "Firefox crashed when screensaver was switching off." "I was just trying to start warcraft 3... It seems that, firefox does not like warcraft... :)" "Listening to music using grooveshark" "in Display Properties, I switched secondary display to primary display - and ff crashed."

Apologies if this is thinking in the wrong direction, but the first two cases in comment #3 and the steps in comment #2 make me think that maybe the device was lost - does (ipc?) plugin drawing code deal with this differently than Firefox proper?

Incidentally, given the connection to bug 611597, most of these crashes appear to be on Windows XP, which does not support Direct3D 9Ex as far as I know - and Direct3D 9 loses devices in many more cases than Direct3D 9Ex.

mTexture is NULL at http://hg.mozilla.org/mozilla-central/annotate/ad227939db82/gfx/layers/d3d9/ImageLayerD3D9.cpp#l497 Yesterday I thought that perhaps we were trying to create a 0-size texture, which Bas said would fail. But that's not it, the minidump shows us trying to create a texture 0xd9 by 0x6f. And the crash comments show: * Unlock screen with Flash app visible * rotated the screen by 90 degrees * I was downloading Firefox4b7 and closing tabs on the only window that I had open. * Browing NYTimes after screen unlock So I'm going to call this a bug in the D3D9 texture code. I'll attach a patch to wallpaper over the failure, but I'm not sure what the effects will be (whether the plugin will stop painting forever, or whether the next paint will recover).

(In reply to comment #6) > mTexture is NULL at > http://hg.mozilla.org/mozilla-central/annotate/ad227939db82/gfx/layers/d3d9/ImageLayerD3D9.cpp#l497 > > Yesterday I thought that perhaps we were trying to create a 0-size texture, > which Bas said would fail. But that's not it, the minidump shows us trying to > create a texture 0xd9 by 0x6f. And the crash comments show: > > * Unlock screen with Flash app visible > * rotated the screen by 90 degrees > * I was downloading Firefox4b7 and closing tabs on the only window that I had > open. > * Browing NYTimes after screen unlock > > So I'm going to call this a bug in the D3D9 texture code. I'll attach a patch > to wallpaper over the failure, but I'm not sure what the effects will be > (whether the plugin will stop painting forever, or whether the next paint will > recover). Ah! So screen lock is the key here. On Windows XP (Non D3D9Ex devices) while the screen is locked the device will be 'lost' will will recover the device next paint instruction and be able to create textures again. (This call will be returning D3DERR_DEVICELOST) We need to be careful here, we could wallpaper over a device lost error, but if the cairo image then isn't updated for a while it will be drawing an empty area until a new cairo image is selected for the container. We could add code to store the image data and upload it on the next Render call if this upload fails.

You may know this, but note that the device cannot be reset until TestCooperativeLevel() (which has to be called from the thread that created the device!) returns D3DERR_DEVICENOTRESET.

Source: http://msdn.microsoft.com/en-us/library/bb174472.aspx

(In reply to comment #8) > You may know this, but note that the device cannot be reset until > TestCooperativeLevel() (which has to be called from the thread that created the > device!) returns D3DERR_DEVICENOTRESET. We actually just try anyway! :-) Reset will just return DEVICELOST: http://mxr.mozilla.org/mozilla-central/source/gfx/layers/d3d9/DeviceManagerD3D9.cpp#503

Ah yes, that looks good, as long as the calling thread is always the thread that created the device :)

Comment on attachment 491594 [details] [diff] [review] Handle texture-creation failure, rev. 1 Looks good to me!