Closed Bug 611593 Opened 14 years ago Closed 14 years ago

plugin crash [@ @0x0 | mozilla::plugins::PPluginInstanceChild::OnCallReceived(IPC::Message const&, IPC::Message*&) ] [@ mozilla::plugins::PPluginInstanceChild::OnCallReceived(IPC::Message const&, IPC::Message*&) ]


(Core Graveyard :: Plug-ins, defect)

Windows XP
Not set


(blocking2.0 beta8+)

Tracking Status
blocking2.0 --- beta8+


(Reporter: scoobidiver, Assigned: benjamin)



(4 keywords)

Crash Data


(1 file)

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 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/
8 	xul.dll 	MessageLoop::DeferOrRunPendingTask 	ipc/chromium/src/base/
9 	xul.dll 	MessageLoop::DoWork 	ipc/chromium/src/base/
10 	xul.dll 	base::MessagePumpForUI::DoRunLoop 	ipc/chromium/src/base/
11 	xul.dll 	base::MessagePumpWin::RunWithDispatcher 	ipc/chromium/src/base/
12 	xul.dll 	base::MessagePumpWin::Run 	ipc/chromium/src/base/message_pump_win.h:78
13 	xul.dll 	MessageLoop::RunInternal 	ipc/chromium/src/base/
14 	xul.dll 	MessageLoop::RunHandler 	
15 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/
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:

More reports at:|%20mozilla%3A%3Aplugins%3A%3APPluginInstanceChild%3A%3AOnCallReceived%28IPC%3A%3AMessage%20const%26%2C%20IPC%3A%3AMessage*%26%29*%26%29
blocking2.0: --- → ?
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.
Assignee: nobody → benjamin
Severity: blocker → critical
blocking2.0: ? → beta8+
Component: IPC → Plug-ins
QA Contact: ipc → plugins
I have found it frustratingly easy to reproduce this with video highlights on 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:
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 (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.
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, 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
Keywords: reproducible
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
Attachment #490556 - Flags: review?(Olli.Pettay)
Attachment #490556 - Flags: review?(Olli.Pettay) → review+
Blocks: 583109
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
Blocks: 564500
Blocks: 612199
Crash Signature: [@ @0x0 | mozilla::plugins::PPluginInstanceChild::OnCallReceived(IPC::Message const&, IPC::Message*&) ] [@ mozilla::plugins::PPluginInstanceChild::OnCallReceived(IPC::Message const&, IPC::Message*&) ]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.