Build: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101111 Firefox/4.0b8pre They are new crash signatures. Crashes first appeared with this build. It is #1 mega top crasher in this build: [@ @0x0 | mozilla::plugins::PPluginInstanceChild::OnCallReceived(IPC::Message const&, IPC::Message*&) ]: 1000 crashes/buildday [@ mozilla::plugins::PPluginInstanceChild::OnCallReceived(IPC::Message const&, IPC::Message*&) ] : 500 crashes/buildday [@ mozilla::plugins::PluginInstanceChild::AnswerNPP_Destroy(short*) ] : 350 crashes/buildday Signature @0x0 | mozilla::plugins::PPluginInstanceChild::OnCallReceived(IPC::Message const&, IPC::Message*&) UUID d9814bd8-a8c0-402f-8704-52b242101111 Process Type plugin Version: Filename: NPSWF32.dll Time 2010-11-11 17:55:58.979300 Uptime 68639 Install Age 70590 seconds (19.6 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 AuthenticAMD family 16 model 6 stepping 2 Crash Reason EXCEPTION_ACCESS_VIOLATION_EXEC Crash Address 0x0 App Notes AdapterVendorID: 10de, AdapterDeviceID: 03d0 Frame Module Signature [Expand] Source 0 @0x0 1 xul.dll mozilla::plugins::PPluginInstanceChild::OnCallReceived obj-firefox/ipc/ipdl/PPluginInstanceChild.cpp:1681 2 xul.dll mozilla::plugins::PPluginModuleChild::OnCallReceived obj-firefox/ipc/ipdl/PPluginModuleChild.cpp:574 3 xul.dll mozilla::ipc::RPCChannel::DispatchIncall ipc/glue/RPCChannel.cpp:517 4 xul.dll mozilla::ipc::RPCChannel::Incall ipc/glue/RPCChannel.cpp:503 5 xul.dll mozilla::ipc::RPCChannel::MaybeProcessDeferredIncall ipc/glue/RPCChannel.cpp:350 6 xul.dll mozilla::ipc::RPCChannel::OnMaybeDequeueOne ipc/glue/RPCChannel.cpp:415 7 xul.dll MessageLoop::RunTask ipc/chromium/src/base/message_loop.cc:343 8 xul.dll MessageLoop::DeferOrRunPendingTask ipc/chromium/src/base/message_loop.cc:351 9 xul.dll MessageLoop::DoWork ipc/chromium/src/base/message_loop.cc:451 10 xul.dll base::MessagePumpForUI::DoRunLoop ipc/chromium/src/base/message_pump_win.cc:213 11 xul.dll base::MessagePumpWin::RunWithDispatcher ipc/chromium/src/base/message_pump_win.cc:52 12 xul.dll base::MessagePumpWin::Run ipc/chromium/src/base/message_pump_win.h:78 13 xul.dll MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:219 14 xul.dll MessageLoop::RunHandler 15 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:176 16 xul.dll XRE_InitChildProcess toolkit/xre/nsEmbedFunctions.cpp:506 17 plugin-container.exe wmain toolkit/xre/nsWindowsWMain.cpp:125 18 plugin-container.exe __tmainCRTStartup obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591 19 kernel32.dll BaseProcessStart 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=%400x0%20|%20mozilla%3A%3Aplugins%3A%3APPluginInstanceChild%3A%3AOnCallReceived%28IPC%3A%3AMessage%20const%26%2C%20IPC%3A%3AMessage*%26%29 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%3Aplugins%3A%3APPluginInstanceChild%3A%3AOnCallReceived%28IPC%3A%3AMessage%20const%26%2C%20IPC%3A%3AMessage*%26%29

I would very much like to have some steps to reproduce this with, or even just pages on which is commonly appears. Note that this is a plugin-process crash, so a bit less serious than a normal browser crash.

I have found it frustratingly easy to reproduce this with video highlights on ustream.tv. To reproduce, start to play back a video then switch to a different tab (so that it's playing in the background). After some time the plugin will crash - though this is speculation, I think it crashes after dom.ipc.plugins.timeoutSecs has passed and the plugin is actually hung. I have also seen painting simply stop after switching to another tab, even with the video paused. Like this, playback still works (i.e. I get audio) but the timer on the controls and the video are frozen. Switching to fullscreen the video plays back fine, but switching back to windowed mode shows the image still frozen.

(In reply to comment #3) > but the timer on the controls and the video are frozen. To clarify: the controls are still interactive (e.g. pausing/resuming playback works) but no animation is shown. In fullscreen mode everything still works.

Emanuel, do you know whether you are using D3D9/D3D10/Direct2D? Can you include the information from the graphics section of about:support?

Adapter Description: NVIDIA GeForce GTS 250 ... Driver Version: 8.17.12.6063 Driver Date: 9-10-2010 Direct2D Enabled: true DirectWrite Enabled: true GPU Accelerated Windows: 1/1 Direct3D 10 Should I try with any of the above disabled?

Though, I doubt the issue is D3D10/D2D-specific as crashes are pretty evenly distributed across different versions of Windows.

Just got another crash with signature @0x0 | mozilla::plugins::PPluginInstanceChild::OnCallReceived(IPC::Message const&, IPC::Message*&) while video was paused in a background tab, but with dom.ipc.plugins.timeoutSecs set to -1. So it's not just being killed by the time-out. Oddly, the crash reporter seems to have sent two reports in quick succession, even though I'm only aware of one crash. IDs e7b851b0-06ce-4931-9e77-f34702101112 and a2443c7f-a659-4749-9f67-61f882101112 respectively.

Is there any Flash running in *foreground* tab, or just the ustream tab? I haven't reproduced the crash yet, and I'd like to reproduce your setup as precisely as I can.

Might bug 609716 comment 5 (str) be related but for mac?

The video freeze happens without any Flash running in other tabs - just browsing around a bit on bugzilla caused the hang. I'm not sure about the crash though ... I'll leave it a bit longer. Just in case, I'm trying to watch http://www.ustream.tv/recorded/10712209 (the TGWTG guys playing some D&D).

Man, even the hang is pretty hard to reproduce ... One thing you can try is pausing the video, doing something else for a while, resuming it, doing something else for a while, then checking to see if it's frozen up. Haven't had a crash in a while - the crashes may only happen if you've looked at something else to do with Flash before returning to or closing the tab with the frozen video. Though I've had it happen without closing the original tab as well.

On a VM with XP and the latest nightly, I was able to reproduce this after about a half hour trying some of the sites and steps mentioned here, using gmail, twitter, ustream, bugzilla. I tried fullscreening the video and doing other things, then I left it playing for a while. What may have triggered it was switching from the video to twitter, back, and closing the tab with video and switching quickly back to twitter. http://crash-stats.mozilla.com/report/index/94c2922f-cae3-44c8-b61e-5bf4e2101112

Just had a Youtube video crash after simply opening a bugzilla e-mail for this bug from Digsby - the plugin seemed to crash the moment I switched back to the video. I don't think there's much I can add at this point unless you need me to run a tryserver build (or a debug build, assuming I can figure out how).

I have been able to reproduce this on 2 machines on formula1.com, closing the tab causes the plugin crash. Both of these crash on the site: Direct2D Enabled true DirectWrite Enabled true GPU Accelerated Windows 1/1 Direct3D 10 Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Windows 1/1 Direct3D 9

I have this in recording, I don't need any more STR, thanks ;-) > xul.dll!mozilla::plugins::PluginInstanceParent::RecvShow(updatedRect={...}, newSurface={...}, prevSurface=0x0027d330) Line 480 xul.dll!mozilla::plugins::PPluginInstanceParent::OnMessageReceived(__msg={...}, __reply=0x00000000) Line 910 xul.dll!mozilla::plugins::PPluginModuleParent::OnMessageReceived(__msg={...}, __reply=0x00000000) Line 570 xul.dll!mozilla::ipc::SyncChannel::OnDispatchMessage(msg={...}) Line 169 xul.dll!mozilla::ipc::RPCChannel::Call(msg=0x0335e918, reply=0x0027d660) Line 257 xul.dll!mozilla::plugins::PPluginInstanceParent::CallNPP_Destroy(rv=0x0027d6d0) Line 588 xul.dll!mozilla::plugins::PluginInstanceParent::Destroy() Line 181 xul.dll!mozilla::plugins::PluginModuleParent::NPP_Destroy(instance=0x082758e4, __formal=0x0027d734) Line 418 xul.dll!nsNPAPIPluginInstance::Stop() Line 213 We receive a Show() call while we are tearing down the plugin. This seems ok (Show is winning the race correctly). Looking at the child process next.

Olli found the bug in bug 583109 comment 55. I'm going to push this assuming r=smaug