Firefox crash when opening an mplayer or Java plugin ubuntu breezy

This is using Mozilla 0.9.4, sorry for omitting it before.

confirming

-->OJI

*** Bug 102748 has been marked as a duplicate of this bug. ***

*** Bug 109140 has been marked as a duplicate of this bug. ***

meta bug to track the separation of browser and plug-ins

*** Bug 62460 has been marked as a duplicate of this bug. ***

*** Bug 43106 has been marked as a duplicate of this bug. ***

*** Bug 59653 has been marked as a duplicate of this bug. ***

This doesn't seem to be a truly meta-bug - there are no bugs this one depends on...
?

bug 58937 is related to this (though probably not blocked by it). beppe, had
time to look into this a bit more?

batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

Are we going to sign up for this? Beppe?

Not for a while, we need to do a lot more digging than what we have up to this
point. We also need to understand how this could work across platforms.

Moving to future until we better understand the impact

Chris Petersen is a new QA contact for oji component. His email is:
<email address hidden>

fixing small error for <email address hidden> (filter with : SPAMMAILSUCKS)

I just killed a rogue java_vm process and it didn't take down the brower. I'm
using j2sdk-1.4.0_02-fcs and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1)
Gecko/20020827.

Of course, the rogue process is a pain in the first place (buring cycles when no
currently loaded page has applets) but I don't see what Moz can do about it.

Anyway, consider this a weak WORKSFORME.

reassign to me

The decision was to not do separate processing. Rather, at least on windows is
to follow the sub-classing work Andrei (169071). This bug remains open for Mac
and Linux work.

This would require extensive work from layout.

Removing topembed+

reassign

beppe: i'm not sure i understand bug 169071 and how that relates to this bug.
would subclassing keep mozilla from crashing if, say, the quicktime plugin puked?

tia,
marc

yes, that is exactly what it is supposed to do, the subclassing "wraps" the
plug-in as to insulate the browser application from bad calls, etc.

Structured exception handling with subclassing will only help crashes in the
window proc on Windows.

Since Quicktime usually crashes in another thread, that likely won't stop it
from bringing down the browser not to mention other plaforms.

This is a meta bug. There is lots of work that this would depend on, like
synchronization, plus lots of toolkit stuff to get the plugin to paint in the
browser and browser events to go to the plugin.

I was looking through the Windows Platform SDK lately and was wondering if
|SetUnhandledExceptionFilter| or |AddVectoredExceptionHandler| in XP would help
catch crashing in other threads?

*** Bug 185839 has been marked as a duplicate of this bug. ***

*** Bug 185803 has been marked as a duplicate of this bug. ***

Confirm on Linux(RH8.0) mozilla1.2 JRE1.4.1.
This bug depends on oji/jpi redesign
Add "redesign" on Whiteboard

*** Bug 187469 has been marked as a duplicate of this bug. ***

*** Bug 193429 has been marked as a duplicate of this bug. ***

A bug in a plug-in can crash the browser.

All calls to entry points to plug-ins should be set up with signal handler to
intercept errors and terminate the plug-in function instead of allowing the
entire browser to crash.

A diagnostic should be displayed when a plug-in hits a fatal error.

As part of the test procedure to verify the browser operation, a set of
plug-ins, one for each entry point that can be called should be made. These
plug-ins should make an illegal memory access. The browser should not crash.

There are many bug reports in Bugzilla about plug-in's crashing the browser, but
 the fixes seem to be concentrating on the specific plug-in, instead of fixing
the common vulnerability in the browser.

> All calls to entry points to plug-ins should be set up with signal handler
> to intercept errors and terminate the plug-in function instead of allowing
> the entire browser to crash.
[...]
> As part of the test procedure to verify the browser operation, a set of
> plug-ins, one for each entry point that can be called should be made. These
> plug-ins should make an illegal memory access. The browser should not crash.

This will not protect Mozilla from a plugin that incorrectly overwrites valid
browser memory. The only way to get real protection from flaky plugins is to run
them in a separate process and have robust handling of the interprocess
communication channel on Mozilla's side.
Just my 2c.

*** Bug 196046 has been marked as a duplicate of this bug. ***

I've got this too. It's a real pain, since sometimes the java_vm can use 100 %
CPU, and even if the mozilla tab is closed on the website that invoked (and
infinite-looped) java, it still doesn't exit.

*** Bug 210232 has been marked as a duplicate of this bug. ***

This seems like a specific case of bug 156493, in which a buggy/unstable plugin
can bring down the entire Mozilla process. There is a great demand for running
plugins as separate processes. If this was done, Mozilla could be tolerant of
plugin malfunctions, and continue to run. If bug 156493 is fixed, then this bug
would also be fixed.

I very much hope that the Mozilla developers can find time to work on bug 156493 :)

*** Bug 214596 has been marked as a duplicate of this bug. ***

is anybody actively working on this?

->kyle

*** Bug 220568 has been marked as a duplicate of this bug. ***

*** Bug 240852 has been marked as a duplicate of this bug. ***

I mentioned in my bug that although Acroread isn't actually freezing, when you
try to exit it, it brings up a dialog to the background asking you whether you
want to exit. Therefore, it seems like it is freezing. Until you disable this
dialog, you get the idea that Acroread is freezing Mozilla.

*** Bug 322997 has been marked as a duplicate of this bug. ***

Hi folks,

some time went by since anything happened here ...
I had a short look at nspluginwrapper. It's now under GPL and seems to compile
fine (not tested running it yet).

If it's stable, I dont see any valid reason not including it into mozilla and
replacing the current plugin loader by it.

BTW: for longer terms, using 9P2000 instead of the (not yet documented)
socket protocol would make it more open and easier to handle. In the spirit
of Plan9 plugins so can rund virtually anywhere.

(In reply to comment #67)
> I had a short look at nspluginwrapper. It's now under GPL and seems to compile
> fine (not tested running it yet).
>
> If it's stable, I dont see any valid reason not including it into mozilla and
> replacing the current plugin loader by it.

GPL license is not compatible for inclusion inside Mozilla (see http://www.mozilla.org/MPL/mpl-faq.html). But the author could still relicense it.

*** Bug 401809 has been marked as a duplicate of this bug. ***

*** Bug 403030 has been marked as a duplicate of this bug. ***

*** Bug 405206 has been marked as a duplicate of this bug. ***

A related data point: Apparently since forever, Shockwave Player has suffered from a bug which causes it to randomly stop processing events (freezing the UI, but not the process) on multi-core computers due to a mis-implemented monitor. It can be worked around by setting the CPU affinity of Firefox to just one core. Should out-of-process plugins be implemented, a white/blacklist of plugin quirks would also be useful...

*** Bug 448370 has been marked as a duplicate of this bug. ***

So, now Google Chrome is out and using a separate process for plugins. Not sure about IE8. This may become a hot topic.

Plug-in scriptability no longer depends on XPCOM; so this doesn't need to depend on bug 242530 anymore. (Which is not to say that XPCOM-based IPC is the wrong solution; just that it isn't obviously the right one.)

*** Bug 457950 has been marked as a duplicate of this bug. ***

I'm not sure this bug is the appropriate place to put "Bug 457950". I wasn't so concerned with a plugin crashing the browser (though that is a concern), I was more concerned that a plugin (Adobe flash) running in one window, wants to use all of the CPU. That's fine. I have 4. But in a separate window, I am still "automatically" limited to only running on the 1 used processor. I have 3 unused processors that can be used to browse or whatever -- but because the one window that's running flash is using such a high level of CPU, Adobe Flash keeps emitting error messages that a "script" (the flash script, I guess) is hogging the CPU (it is -- it's playing a hi-def movie that's barely being kept in sync -- probably a poor implementation by nbc.com), but I want to allow it to have its own CPU -- and keep browsing in *other* cpu's.

When a plugin is using 80% of 1 cpu (as in my bug), the adobe flash player detects the high Cpu usage and high latency and brings up warning messages. There isn't a CPU crisis -- it's just 1 cpu that's busy. Why can't those plugins get a separate thread ? Maybe __at least__ allow other WINDOWS to use other CPU's -- That's the bug. When firefox is already using 100% of one cpu, it still blocks another instance of firefox from starting to run on another cpu. It forces all windows to the same cpu.

Why not make access to the profile protected with 'locks' and/or shared memory to hold a common state?

This is the biggest value of Googles new browser over Firefox -- you can bet MS will have IE be multithreaded, but I saw Google's browser release being a direct competition to Firefox because FF is limited to 1 thread. They are both open source -- they can both converge to a similar feature set -- but Google's browser isn't based on mono-threaded code so it can expand. FF is stuck.
I could easily upgrade my system to eight cores -- but what would be the point? I can't even make due with 4 cores, yet I am very often CPU bound in 1 core due to Firefox's stuck implementation.

In fact -- I don't require that the browser stay up if a plugin crashes -- that's far less common of an occurrence for me. What is common is that every day, every FF window and tab are run in a small quarter-sized compartment in my computer because FF is so poorly written.

Why was it written as single threaded in the first place? Seems like poor design from the start. By default, code should be re-entrant and only non reentrant by special exception or necessity. This has been a problem since the beginning, yet it keeps getting put off to some vague nebulous future.

What's the problem -- as even IE will supposedly run on separate cores (not sure if that was referring to future or now)?

But if bug 457950 doesn't require the browser to "not crash" when a plug-in crashes, is it really the same bug as this one?

Google is doing the right thing with Chrome, by putting every tab/plugin in its own process. And Microsoft is doing the same in IE8. Hopefully the Firefox team will come to their senses and do the right thing here. This bug is 6 years old, so clearly this kind of user feedback isn't especially important to the Firefox team; hopefully pressure from the competition will be treated a little more seriously.

It is my sincere hope that when Google Chrome is completely open-sourced for all operating systems, the Chrome and Firefox teams can come to an agreement.

Firefox 4.0 = Combining the best features of Firefox 3.x and Google Chrome!

Top of the list would have to be this bug. You can tell a lot of people want this feature, because it's among the top things Google Chrome advertises as being improvements.

(In reply to comment #77)
> I'm not sure this bug is the appropriate place to put "Bug 457950". I wasn't
> so concerned with a plugin crashing the browser (though that is a concern), I
> was more concerned that a plugin (Adobe flash) running in one window, wants to
> use all of the CPU.

The issue is different from the user perspective, but the solution is identical: run plugins in their own process. From a development perspective it's the same request.

Yes, you could solve your problem by using only threads, not processes, but that's unlikely to happen precisely because it doesn't solve the security problem, whereas using separate processes *would* help to solve the multicore utilization problem.

> There isn't a CPU crisis -- it's just 1 cpu that's busy. Why can't those
> plugins get a separate thread ?

They can. That's what this bug requests. It will just take a considerable amount of development work.

FYI, this is not being ignored, IE8 and Chrome have gotten Mozilla talking about process-per-tab (and I guess -per-plugin too). See some discussion here, at least on process-per-tab:

http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/06b9aade0a0ee360/830bbe3487eb91ae

But I get the impression that it's going to take a lot of work to implement.

*** Bug 460527 has been marked as a duplicate of this bug. ***

*** Bug 471327 has been marked as a duplicate of this bug. ***

*** Bug 486636 has been marked as a duplicate of this bug. ***

There's work underway to do this, but it won't be done for 1.9.2.

If you want, I can test it using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090903 SeaMonkey/2.0b2pre ID:20090903004335 if you give instructions.

*** Bug 533866 has been marked as a duplicate of this bug. ***

From what I noticed, nspluginwrapper installed by default even on non-64-bit, does this currently.

When Flash Player goes bye bye, Firefox is still working. Like in Opera, refresh is required to make it back.

Ah. Therein lies the confusion. The problem for me isn't that flash crashes; it's that flash is running (and that background tabs don't suspend it). Consider several windows with perhaps 50 tabs. Each of them may have an instance of the flash player. The firefox CPU usage hits 100%, firefox slows to a crawl, and the OOM killer eventually clobbers firefox.

Richard, you are introducing confusion into the matter. What you need in described situation is a flash blocking extension, like https://addons.mozilla.org/en-US/firefox/addon/433.

It will solve your problem completely.

This bug is about a significant architectural rework of Mozilla's browser plugin subsystem, regardless of whether we're talking about Flash, Java applets, or VRML renderers.

*** Bug 180946 has been marked as a duplicate of this bug. ***

*** Bug 538100 has been marked as a duplicate of this bug. ***

This bug is being worked on for a release that should come shortly after Firefox 3.6. That work is being tracked in bug 539055 / bug 531142.

There is another problem with it...
Enabling the separate process for the plugins in the latest trunk cause the plugins to freeze...
They just begins to execute, but after some seconds they just won't react!
This behaviour is with Flash Player (with nspluginwrapper) and mplayer-mozilla... Probably others also...

Evengard, it's not even alpha quality yet - that's why it's only available in the 3.7a1pre builds (nightly builds). You're probably seeing bug 542263 or bug 543303.

I don't think it is really those bugs, because turning it off the plugins works just fine...

This was fixed with the release of Firefox 3.6.4.

To be clear, it's only partly fixed on Firefox 3.6.4:
 * only a specific list of plugins are out-of-process (silverlight, flash, and quicktime)
 * out-of-process support in 3.6.4 is only on Windows and Linux (not Mac)

However, on mozilla-central:
 * all plugins are out-of-process
 * it works on Windows, Linux, and Mac

So based on the state on mozilla-central, the resolution in the previous comment that this bug is FIXED is correct, since bug resolutions reflect what's in mozilla-central. The current situation on mozilla-central will hopefully be what ships in Firefox 4.

I'm running Firefox 3.6.6 on Linux (Kubuntu 10.04 64 bits) and it still freezes when flash freezes. All windows must be terminated when flash freezes.

Is the flash plugin loading through some file other than libflashplayer.so ?

Because only libflashplayer.so is whitelisted (see comment 96). The whitelisting happens through the line:
pref("dom.ipc.plugins.enabled.libflashplayer.so", true);
in defaults/pref/firefox.js (which, on Ubuntu, is in /usr/lib/firefox-3.6.6).

Thanks for the info, David. How do I verify that?
In about:plugins, I see:

Shockwave Flash
File: npwrapper.libflashplayer.so

Does this mean that the file through which flash is loaded is npwrapper, which is not whitelisted? Can I whitelist it? If yes, do I need to whitelist "npwrapper" or "npwrapper.libflashplayer.so"?

Thanks

marcelo, and everyone else:
Bugzilla is *NOT* a support forum.

please do not ask questions in resolved bugs.

for support, please visit http://support.mozilla.com

fwiw, you would have to whitelist the entire filename, not just some random substring.

timeless, the bug is not resolved for me in Firefox 3.6.6 and comment #96 says it should be starting in version 3.6.4. I'm trying to determine if the bug is indeed fixed or not.
I'm not asking general support questions.

Marcelo, the bug is fixed. If there's a problem for you, it's most likely that the 64bit Linux installs which use a 32bit plugin wrapper for Flash are not whitelisted yet.

That smells strongly of a separate bug. It may already exist, and it may really belong with Kubuntu/Ubuntu (which have packaged the flash plugin as such.) If it's Mozilla's territory, and there's no bug yet, then you should probably file a new one depending on this or some such.

In any case, trying to determine how to use the about:config prefs for this is definitely support, so seems like that belongs where timeless said.

-[Unknown]

Bug 176280 was marked as a duplicate of this one (156493). For that reason, I'm reporting a new instance of that bug here. It's a bug where the Java fphover package causes infinite warning boxes.

I just experienced this problem again, many years after the previous report, when visiting www.chakraplein.nl/allin_taylor.htm. I am running Java 1.7.0 (the latest). Firefox 19.0.2, Windows XP Home SP3, computer otherwise running well. I have already also entered this info at bug 176280.

In my opinion, the problem should be fixed (in Mozilla) because it looks exactly like malware (a phishing attempt to get the user to click OK to gain access to install malware). If someone can replicate this report, I recommend it be fixed since it gives the appearance of being a serious bug (it isn't really a serious problem, but unsophisticated users may not realize that, because it makes the browser stop responding).