Firefox Lorentz Keeps Plugin Crashes Under Control
pastababa writes "A beta of the Firefox Lorentz project is now available for download and public testing. Eming reports Firefox 'Lorentz' provides uninterrupted browsing for Windows and Linux users when there is a crash in plugins. Plugins run in a separate process from the browser. If a plugin crashes it will not crash the browser, and unresponsive plugins are automatically restarted. The process-isolation feature has been in Google's Chrome from the beginning. Chrome sandboxes individual tabs, and the crash of one tab does not affect the running of the rest of Chrome browser. Firefox currently isolates only Adobe Flash, Apple Quicktime, and Microsoft Silverlight, but will eventually isolate all plugins running on a page. Mozilla encourages users to test Firefox 'Lorentz' on their favorite websites. Users who install Firefox 'Lorentz' will eventually be automatically updated to a future version of Firefox 3.6 in which this feature is included."
Versions of Gnash have frequently segfaulted on my Linux box (the segfault is reported by dmesg), yet I've never had a browser crash because of it. I had thought that plugins were already isolated enough from the application as a whole.
but can it be extended so that plugins are not only run in their separate processes, but separate SELinux sandboxes as well?
Colorless green Cthulhu waits dreaming furiously.
lorentz is just one more thing that can crash. Am i right?
Maybe you disagree with me on this, but from my perspective:
1. Firefox plugins rarely (in my case, never) crash.
2. Chrome is a beta browser, so I'm not going to use it for day-to-day tasks.
I'm tired of stories comparing Chrome and Firefox. Once Chrome reaches v1.0 and is considered by Google to be production-ready, then I'll care. Until then, it's an interesting tech-demo and nothing more.
Hmm, Google Chrome already handles plugins this way, but one flash-heavy site I know delivers a lot of streaming video and absolutely will crash either Firefox or Chrome in linux (I use Mint, mainly) without fail, if given enough time, Gnome or KDE. Crash as in the entire browser becomes unresponsive and must force-close. After it did this to Firefox a few times I tried Chrome, with the same result. Everything will be fine for a few minutes, sometimes up to an hour or so, then the whole browser will die. Haven't tried IE, tried Firefox with Windows 7 and had the same thing happen. I will certainly look into anything that prevents crashes for Firefox, since I strongly prefer it to every other browser I've tried, since most of the time it works perfectly.
This is a hacked account, for which the owner can not be held responsible.
Why didn't we have this stuff in the late nineties?
We've known about plugin crashiness for a long time. We're just now going multi-process for this?
Selah.ca. Pause, and calmly think on that.
Let's see how it goes. The auto-restart of plugins should be good, but could also cause a plugin DOS.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Hey dipshit. The rest of the computing world doesn't what some random idiot on Slashdot like you has to say about what version number a browser is labeled with.
Chrome absolute destroys the STINKING PILE OF FAIL that is Firefox in speed, resource usage, stability, and every other possible metric with the single exception of Ad blocking versus hiding. And even that is soon to change.
So go right ahead retard and keep using your 'production-ready' piece of shit browser. No one gives a crap.
No, this has not been the normal plugin architecture. When Linux moved to 64-bit, firefox was ported to 64-bit but all of the proprietary plugins were still 32-bit. The solution to this problem was to create nspluginwrapper which would run the apps in a separate process. It had some bugs of it's own, wasn't always reliable about letting you restart crashed plugins, and has itself crashed the browser on me, but it largely prevented plugins from crashing the browser as a side effect.
Older 32-bit versions of firefox on linux, and all versions on windows did not have this capability.
try
{
callpluginfunction();
}
catch (...)
{
whoops();
}
C'mon people! Let's get our shit together here
Does this mean an attacker gets to try repeatedly to break ASLR, instead of just once?
Assuming, of course, that garbage like flash actually did ASLR.
Does this mean that, when "Lorentz" covers all plugins, we can install and update plugins without having to restart Firefox?
That would be a worthwhile feature. It's annoying having to restart the browser for any plugin changes.
use minefield http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
I crash Firefox several times a day right now. I leave it running all day and when I come back to the machine it's toast 9 times out of 10. I think it's a combination of Flash! and Java but other things seem to take it out too. I finally got pissed and found out more about how to look at the Firefox bug reports and am slowly trying to add more info to the ones that plague me! this one https://bugzilla.mozilla.org/show_bug.cgi?id=537630 is a bitch for instance. If you want to see yours put this in the address bar -> about:crashes and it will show you what it has and hasn't submitted successfully. I've loaded this new code up and will take it for a spin on sites that normally trash me - so far so good though and it is handling session saver etc. just fine! Painless "upgrade"...
Build it, Drive it, Improve it! Hybridz.org
and as usual no x86_64 build to be found.
Firefox currently isolate [sic] only Adobe Flash, Apple Quicktime and Microsoft Silverlight, but will eventually isolate all plugins running on a page.
The quote emphasizes that Lorentz affects only plugins, not extensions, a distinction that seems to be escaping many posters.
I've had flash behave pretty screwily short of crashing, so this might be nicer if it included a mechanism to manually stop & restart plugins. Perhaps it will expose API allowing other add-ons to do so.
The plugin that gives me by far the most trouble (on Windows) is Adobe Acrobat Reader. I can already restart that (by killing the process) without crashing firefox.
Goddamnit!! Fix it, you useless shits!!!
There appears to be a download for Mac available right at the same link - but from the FAQ:
2. Why aren't multi-process plugins available on Mac?
Mozilla is working on making multi-process plugins available on Mac. Because of architectural differences, the code is not ready for beta testing.
#DeleteChrome
Can anyone please explain to me why there's a need for completely new processes, as opposed to using threads?
I'm curious as to what's the difference, and where the thread mechanism "fails" here.
Something that can make Mozilla more stable...
It sounds like...
Quite a transformation!
Yeeaahhh!
Crashes are a hassle for sure, but if you're lucky and don't have an unstable plugin installed, you rarely crash. What I tend to see is runaway memory and CPU usage that forces me to close the browser and start again.
These posts express my own personal views, not those of my employer
I'm using it now and I like it, but Chrome is not stable for me.
It's problem is that it gets "stuck" in flash in such a way that nothing on my system can use the sound card.
I can kill off all the tabs but there's still a chrome process running and until I kill that manually I can't play any music.
I find this an incredible nuisance. Firefox has the same problem but when I kill it it's gone - no processes left behind.
This is all just my personal opinion.
> Chrome sandboxes individual tabs, crashes of one tab does not affect the running of the rest of Chrome browser.
Will Chrome also restart sentences in the event of comma splices?
Well, I would gladly test this. But "automatically updated to a future version of Firefox 3.6"? I normally wait about a week for my critical extensions to catch up to a new release. Potentially a week without Tab Mix Plus? No thanks.
Been running nightly 64-bit Firefox, automatically updated. I guess I got Lorentz a couple of nights ago, not sure when because I was traveling.
Now no Flash instances run, they take 30 seconds or more to "initialize" before they crash, and the entire Lorentz-enabled Firefox browser crashed on me once. It just suddenly and unexpectedly disappeared. It's been a year or more since Firefox crashed on me.
So at this point there are lots of bugs to shake out. Going back to vanilla 3.6.3 for the time being.
sigfault (core dumped)
Fixit!Fixit!Fixit!Fixit!Fixit!Fixit!Fixit!Fixit!Fixit!
Fixit!Fixit!
---
System response: Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition.
"I'm sorry, whaaa?"
"Good news, everyone! I violated the 'postercomment' compression filter! Wheeee!"
sigfault (core dumped)
Jam a bastard in it, you crap!
sigfault (core dumped)
While plugin process isolation is absolutely essential, per-tab/window process isolation is also highly desirable - it's incredibly annoying when misbehaving _javascript_ on one tab causes all other tabs to freeze (not crash). That's not a plugin issue, of course, but it shows that _both_ chrome's process-per-tab and firefox process-per-plugin-instance approaches are desirable
has been in Google's Chrome from the beginning.
...and has been in UN*X versions of Opera probably since the dawn of time.
but based on the subject, this message could be about anything.
The process-isolation feature has been in Google's Chrome from the beginning. Chrome sandboxes individual tabs, and the crash of one tab does not affect the running of the rest of Chrome browser.
Geez thanks, I wouldn't know it without that, Now I can comfortably ready about something unrelated.
IE8 already has this feature!
Largely because they do not realise how useful it can be...
As someone who uses remote X regularly, I think the above is a really odd thing to say about a GUI.
Windows and Mac graphics have had network transparency for a while, but anyone using them who wants to explore in that direction can do so by clicking on icons with a mouse. This disparity is a reason why people like me hate the typical X11+whatever subsystem stacks: OS features (including features of the GUI subsystem itself) are seldom discoverable when using that self same GUI.
If I were the Xorg devs, I would be doing 2 things right now: 1) Change X11 config files to XML so there aren't 1,000+ ways to arrange and interpret them, while adding live set/load/save features to the API and make the Xorg program responsible for managing its own damn settings. 2) Getting on my knees if necessary, try to cut a deal with the Nomachine people to allow inclusion of NXserver tech in Xorg for free. 2a) Create proof of concept programs that allow average users to view & manipulate shared desktops and documents onscreen the way Mac and Window users can (without resorting to slow 1980s tech like VNC).
In summary: X11's vaunted net transparency isn't really GUI-accessible or discoverable, and the feature itself can be inefficient and restrictive (one user per window at a time) for modern use cases like collaborating over Internet, etc. So it ain't all its cracked up to be...
As for me and my house I will wait for the Foxfire to update to 3.6 version.
Dale May