Closed Bug 567645 Opened 14 years ago Closed 14 years ago

[OOPP]Flash plugin crashes when click flash video and/or video control on certain page


(Core Graveyard :: Plug-ins, defect)

Windows 7
Not set


(blocking2.0 alpha4+)

Tracking Status
blocking2.0 --- alpha4+


(Reporter: alice0775, Assigned: cjones)



(Keywords: regression)


(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100523 Minefield/3.7a5pre ID:20100523040016
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100523 Minefield/3.7a5pre ID:20100523040016

Flash plugins crashes when click flash video and/or video control on certain page.
See Mozilazine forum .

If OOPP disabled, no crashes.

Reproducible: Always

Steps to Reproduce:
1. Start Minfield with new profile
2. Open URL ( )
3. Click flash video and/or video control
Actual Results:
 Flash plugin crashes.

Expected Results:
 no crash.

Regression window:

Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100521 Minefield/3.7a5pre ID:20100522125027

Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100522 Minefield/3.7a5pre ID:20100522132815

Got Crash IDs?
(In reply to comment #1)
> Got Crash IDs?

The Adobe Flash plugin has crashed.
No report available.
cjones, looks like a regression from your IPDL commits. Did you make something stricter so that there might be more/stricter checking somewhere?
Assignee: nobody → jones.chris.g
blocking2.0: --- → alpha4+
 	mozalloc.dll!mozalloc_abort(msg=0x002df244)  Line 75	C++
 	xul.dll!NS_DebugBreak_P(aSeverity=0x00000003, aStr=0x70b273f8, aExpr=0x00000000, aFile=0x70b27390, aLine=0x0000071b)  Line 359	C++
 	xul.dll!mozilla::plugins::PPluginInstanceChild::FatalError(msg=0x70804186)  Line 1819	C++
>	xul.dll!mozilla::plugins::PPluginInstanceChild::OnCallReceived(__msg={...}, __reply=0x00000000)  Line 1188	C++
 	xul.dll!mozilla::plugins::PPluginModuleChild::OnCallReceived(__msg={...}, __reply=0x00000000)  Line 460	C++
 	xul.dll!mozilla::ipc::RPCChannel::DispatchIncall(call={...})  Line 511	C++
 	xul.dll!mozilla::ipc::RPCChannel::Incall(call={...}, stackDepth=0x00000000)  Line 497	C++
 	xul.dll!mozilla::ipc::RPCChannel::OnMaybeDequeueOne()  Line 434	C++
 	xul.dll!MessageLoop::RunTask(task=0x00000000)  Line 337	C++
 	xul.dll!MessageLoop::DeferOrRunPendingTask(pending_task={...})  Line 347	C++
 	xul.dll!MessageLoop::DoWork()  Line 444	C++

Does mozalloc_abort not trigger breakpad!?
This appears to be a failure-to-deserialize, but it looks like we're deserializing the wrong message type:

    case PPluginInstance::Msg___delete____ID:
            if (mozilla::ipc::LoggingEnabled()) {
                (static_cast<const PPluginInstance::Msg___delete__*>((&(__msg))))->Log("[PPluginInstanceChild] Received ", stderr);

            void* __iter = 0;
            PPluginInstanceChild* actor;

            if ((!(Read((&(actor)), (&(__msg)), (&(__iter)), false)))) {
                FatalError("error deserializing (better message TODO)");
                return MsgValueError;

But the message is actually a NPP_HandleEvent message:

-		__msg	{name_=0x70b26068 "PPluginInstance::Msg_NPP_HandleEvent" }	const IPC::Message &
+		Pickle	{header_=0x007175c0 header_size_=0x00000018 capacity_=0x00000040 ...}	Pickle
+		__vfptr	0x70b2e84c const IPC::Message::`vftable'	*
+		name_	0x70b26068 "PPluginInstance::Msg_NPP_HandleEvent"	const char *

The parent stack confirms that NPP_HandleEvent is being sent, although I can't get the actual __msg on the parent in an opt build.
The same on XP SP3...
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100523 Minefield/3.7a5pre ID:20100523040016
Crashes happen only in situations where OOPP causes very high CPU usage by firefox.exe.  Such as all youtube user profiles,, and other locations.

Situations where plugin container works normally without high CPU usage from firefox.exe seems to function normally. 

If OOPP is not making firefox.exe use a lot of CPU, there are no crashes.
(In reply to comment #7)
> The same on XP SP3...
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100523
> Minefield/3.7a5pre ID:20100523040016

Same here with latest nightly. No crash report.

Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100524 Minefield/3.7a5pre Firefox/3.6
Same here started in:
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; pl; rv:1.9.3a5pre) Gecko/20100524 Minefield/3.7a5pre (.NET CLR 3.5.30729)

yesterday build was working, today's not

Win7 x64
I cannot view Hulu or use Photobucket without a crash.



Not able to reproduce on 3.6.5pre.

Benjamin, did you mean to mark it as blocking alpha5?
Comment 13. I am referring to Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100524 Minefield/3.7a5pre
as that is what the original bug was filed against. This is blocking my ability to use a site and it is more than just an annoyance.
I have the crash here with flash 10.1, I have had reports of people with flash 10.0 not having the crash.
To comment 17, I have had crashes using flash 10.0

Crash report with Flash 10.0
Gary: please do not try to use markup in bugzilla. if you have a bp- id, just list it, bugzilla will figure it out.

bp-ceda782b-983d-4977-95af-1ed11aa49745 Oh Noes! can't find report
bp-ca34c9e9-0815-47dc-bb83-752632100523 UnhandledExceptionFilter
bp-702a144a-53bc-4688-8c67-150202100524 ShouldContinueFromReplyTimeout / mozilla::plugins::parent::_evaluate
bp-a599960a-7cb9-4ac6-9807-13a452100524 ShouldContinueFromReplyTimeout / nsWindow::SetIMEEnabled
bp-518a2833-2363-43b8-8722-e0d032100524 ShouldContinueFromReplyTimeout / nsWindow::SetIMEEnabled
bp-39fd1ad6-aecc-4978-92a7-cb5402100523 ShouldContinueFromReplyTimeout / nsWindow::SetIMEEnabled
Is this ever going to move up the Bug Chain?


This is far more than an annoyance.
Attachment #447420 - Flags: review?(jmathies) → review?(bent.mozilla)
Comment on attachment 447420 [details] [diff] [review]
Temporary workaround

>+                // fix will be to stop trying to remove these events

Nit: "remote"? "send"?
Attachment #447420 - Flags: review?(bent.mozilla) → review+
Closed: 14 years ago
Resolution: --- → DUPLICATE
Comment on attachment 447420 [details] [diff] [review]
Temporary workaround

>+              // FIXME/bug 567465: temporarily work around unhandled

Nit: 567465 s/b 567645
The band aide approach is not going to fix the problem. It will happen again and again...
I got a snooty response from the developers about this plugin-container. They basically told me to go f myself, I have the records if you want me to share.

 Also tried to tell me that major crashing is because of my computer and not this new "plugin-container.exe". Also they claimed that the vast majority of end-users have no issues. 

 So the rest of the million users can go f off because plugin-container.exe is just that cool.

Alex, this bug or any other bug is not the place for this, please take it to the news groups or mozillazine forums.  If you have a specific bug problem, first file a new bug so it can be addressed.  

Plugin-container.exe is a helper file to make specific plugins function without crashing the whole browser.
They is great in theory, but not once have I ever had an issue with flash crashing FF, until now. 

 Now, this bright shiny new plugin-container.exe crashes pages, makes my system hang, and browsing flash containing sites is out of the question. And all I get from my bug report is, "it's your system", "it's flash", etc...

 And then flat out denial that it is even a bug. When in fact there are reports here, and thousands more when you google plugin-container.exe.
@ Alex - create your OWN bug
write when do you got this bug, is it reproducible or where

and stop talking that cointainer is usefull without OWN proofs of guilty
And exactly what are you doing? lol and what?
Okay before this gets out of hand with flaming each other I will simply state my findings on this matter. But first. Alex I do agree with you on the simple matter that people tend to find someone or something else to blame before accepting the fact that the hard work is buggy. and HaWaN you asked if it is reproducible and where. From what I noticed in many of my machines and machines I work on this bug crashes mainly when opening to many tabs with heavy flash in them. Also it crashes when you try and enable your webcam in sites such as stickam or tinychat. My findings are as such and I have checked to see if it was my machine or if it was the screw up in this plugin-container. I have tested this on not 1 not 2 but 6 computers all together 4 desktops and 2 laptops. Now then. Who ever is responsible for this plugin-container needs to do the following. 1 test mainly around flash pages that request permission for your webcam/microphone. 2 run this in debug mode and figure out where the problem arises to better pen point the problem area (although it seems like a memory leak to me). 3 test every possible scenario for the fix until one is found. 4 give people some comfort that something IS being done to fix the problem. And last but not least try and find a temp fix that will lower the crash count until a permanent fix is found. This isn't a big thing for the dev team I'm sure.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.