Closed Bug 156493 Opened 22 years ago Closed 14 years ago

Browser should tolerate plug-in (plugin) malfunctions, like with a separate (own) process

Categories

(Core Graveyard :: Plug-ins, defect, P3)

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla2.0

People

(Reporter: rubydoo123, Unassigned)

References

Details

(Keywords: dataloss, meta, topembed-, Whiteboard: [PL2:P1][Threading/Process]) 

meta bug to track the separation of browser and plug-ins
Severity: normal → critical
Priority: -- → P2
Whiteboard: [PL2:P1]
Target Milestone: --- → mozilla1.0.3
*** Bug 62460 has been marked as a duplicate of this bug. ***
Keywords: meta
*** Bug 43106 has been marked as a duplicate of this bug. ***
Blocks: advocacybugs
Blocks: 58339
Target Milestone: mozilla1.0.3 → mozilla1.1alpha
Severity: critical → normal
Priority: P2 → P1
Keywords: meta
Summary: Meta: browser should tolerate plug-in malfunctions, like with a separate process → Browser should tolerate plug-in malfunctions, like with a separate process
Whiteboard: [PL2:P1] → [PL2:P1][Threading/Process]
*** Bug 59653 has been marked as a duplicate of this bug. ***
Blocks: 74080
Target Milestone: mozilla1.1alpha → mozilla1.2beta
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
Keywords: topembed
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
Target Milestone: mozilla1.2beta → Future
Keywords: topembed → topembed+
Blocks: grouper
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+
Keywords: topembed+ → topembed-
reassign
Assignee: beppe → peterl
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?
Severity: normal → enhancement
Depends on: ipc
Keywords: meta
Priority: P1 → P3
*** Bug 185839 has been marked as a duplicate of this bug. ***
*** 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.
Blocks: 176280
*** Bug 196046 has been marked as a duplicate of this bug. ***
No longer depends on: ipc
*** Bug 214596 has been marked as a duplicate of this bug. ***
is anybody actively working on this?
*** 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 246484 has been marked as a duplicate of this bug. ***
Hopefully with the new plug-in interface (as announced here:
http://developers.slashdot.org/article.pl?sid=04/06/30/1258204) will not be
plagued by this issue.
I again had an issue with this bug. This time it was java_vm bringing down. Bug
102474 depends on this, as mentioned in
http://bugzilla.mozilla.org/show_bug.cgi?id=102474#c14
Blocks: 102474
Severity: enhancement → major
Keywords: dataloss
re: comment #26, it looks to me like the new stuff is just a set of extensions
to the old API and doesn't enforce separation of browser and plug-ins.  we're
still going to be stuck with this plague...

i don't think there's anything about the current API that keeps one from
separating the browser from the plug-in.  it's just a lot of work that nobody
with the requisite skills seems willing to take on.
*** Bug 270543 has been marked as a duplicate of this bug. ***
Summary: Browser should tolerate plug-in malfunctions, like with a separate process → Browser should tolerate plug-in (plugin) malfunctions, like with a separate (own) process
*** Bug 273602 has been marked as a duplicate of this bug. ***
*** Bug 280913 has been marked as a duplicate of this bug. ***
*** Bug 266653 has been marked as a duplicate of this bug. ***
*** Bug 290828 has been marked as a duplicate of this bug. ***
No longer blocks: 176280
*** Bug 176280 has been marked as a duplicate of this bug. ***
This would seem to need bug 242530 in order to maintain scriptability in a
general way.
No longer blocks: 58339, 74080
Depends on: 242530
*** Bug 294327 has been marked as a duplicate of this bug. ***
*** Bug 226843 has been marked as a duplicate of this bug. ***
*** Bug 242914 has been marked as a duplicate of this bug. ***
Blocks: 200511
Blocks: 300756
Blocks: 253117
Flags: blocking-aviary2.0?
bumping to core noms
Flags: blocking-aviary2? → blocking1.8.1?
maybe moving the plugin to a external process, its possible, as we can see with this layer for x86_64 firefox being able to run x86 plugins

http://www.gibix.net/projects/nspluginwrapper/

for now this "proxy" isnt gpl, but (i hope) it will be in the future
at least the idea seens a good one to change as little as possible the plugin interface but still enable the plugins to crash (and like nspluginwrapper, enable x86 plugins support to other platforms)


> i don't think there's anything about the current API that keeps one from
separating the browser from the plug-in.  it's just a lot of work that nobody
with the requisite skills seems willing to take on.

Actually, through the current plugin API (unlike the Netscape 4 plugin API), you can get the Service Manager object, and from that, you can request a whole lot of possible XPCOM services. To replicate this environment in a separate process, we'll need bug 242520 fixed.
Bug 242530, you mean.

And yes, it's possible. I've done it on Linux. And RealPlayer does it on Linux, too, I believe. But doing it cross-platform with a scriptable plug-in is a whole lot of work without bug 242530.

What is "possible"? You can declare that the service manager and the DOM are not accessible to the plugin -- and simply not offer that feature to plugins anymore. Most plugins, which aim for compatibility with the lowest common denominator -- Netscape 4, Konqueror, Opera -- might still work, as they don't rely on the Mozilla-specific plugin goodies.
Anything's possible. I could conceivably implement code such as would resolve bug 242530 in my plug-in. It would be a lot of work and no other plug-in would be able to see the benefit. So, better that go in the browser.

Resolving bug 242530 would give plug-in developers the tools to create out-of-process plug-ins. But once that code is in place, it also becomes possible to move the plug-in harness itself out-of-process, which means *any* plug-in could be run out-of-process.
*** Bug 320696 has been marked as a duplicate of this bug. ***
*** Bug 333424 has been marked as a duplicate of this bug. ***
Not a blocker: too invasive for 1.8.1.
Flags: blocking1.8.1? → blocking1.8.1-
Assignee: peterl-bugs → nobody
QA Contact: shrir → plugins
*** Bug 334853 has been marked as a duplicate of this bug. ***
As a follow up to bug 334853, which has been marked as a dulicate...The attachment created during the crash seems to have been automatically deleted or something. Perhaps it has already been submitted to you somehow? But, I don't have it anymore.

Also, I've posted a related bug to the VLC developers if it is of any interest.
http://forum.videolan.org/viewtopic.php?p=61712
*** Bug 325512 has been marked as a duplicate of this bug. ***
*** Bug 250496 has been marked as a duplicate of this bug. ***
where does bug 230017 fit in dependencies?
(In reply to comment #53)
> where does bug 230017 fit in dependencies?
> 

But 230017 is about running plugins in another thread. It is a possible way to achieve the goal of this bug, but may not be a sufficient.
*** Bug 286717 has been marked as a duplicate of this bug. ***
Does XPCOM support anything equivalent to M$ COM out-of-proc servers, where the COM servers run inside a separate process, and the transfer of data between the interfaces living in the two processes in handled by COM (a process known as marshaling)?

If yes, then maybe this can be used to solve this bug?
It does not. That's what bug 242530 is about.
No longer blocks: 300756
*** Bug 350820 has been marked as a duplicate of this bug. ***
*** Bug 351473 has been marked as a duplicate of this bug. ***
*** Bug 345642 has been marked as a duplicate of this bug. ***
*** Bug 350146 has been marked as a duplicate of this bug. ***
*** Bug 352995 has been marked as a duplicate of this bug. ***
*** Bug 358885 has been marked as a duplicate of this bug. ***
Don't know if it helps, but here are the Event Properties of a such Firefox crash on WinXP:

Faulting application firefox.exe, version 1.8.20061.1023, faulting module jpinscp.dll, version 5.0.60.5, fault address 0x00007f3a.

It's a java malfunction, always at the same address.
Can someone check it?
lmocsi@gmail.com: this bug has a summary, it should be clear that your comment is not appropriate for this bug. find or file a different bug.
Blocks: multicore
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.
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...
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.)
No longer depends on: 242530
No longer blocks: 200511
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.
Flags: blocking1.9.2?
There's work underway to do this, but it won't be done for 1.9.2.
Flags: blocking1.9.2? → blocking1.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.
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.
See Also: → https://launchpad.net/bugs/2697
See Also: → https://launchpad.net/bugs/24199
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...
Target Milestone: Future → mozilla1.9.3
This was fixed with the release of Firefox 3.6.4.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
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]
Target Milestone: mozilla1.9.3 → mozilla2.0
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).
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.