Very similar to bug 59653, but the browser isn't crashing, just getting stuck. When RealPlayer crashes (a common occurence, at least on Linux), mozilla gets stuck continuously trying to read from a bad file descriptor. It really should catch this and error out instead of endlessly looping, requiring you to kill it. Sorry, don't have a debugging build around to track down where the read() is coming from.

OK, here's an strace. write(40, "1030:", 5) = -1 EPIPE (Broken pipe) --- SIGPIPE (Broken pipe) --- close(37) = 0 close(40) = 0 kill(17447, SIGTERM) = 0 read(-1, 0xbfffbbd8, 8192) = -1 EBADF (Bad file descriptor) read(-1, 0xbfffbbd8, 8192) = -1 EBADF (Bad file descriptor) read(-1, 0xbfffbbd8, 8192) = -1 EBADF (Bad file descriptor) ... you get the idea. fd 40 is the communication channel to the plugin, I assume.

well, very few people here are able to even play realplayer on linux :( (there's a bug on that ). We are still yet to find out what's the reason exactly. Bill, could you pls specify your OS version and whatever you think significant so that we know why it is working for you and not working for us. Thanks!

Red Hat 7 (of course ;) ), using blizzard's 2000120516 build of mozilla I hadn't actually tried RealPlayer before this weekend. As for RealPlayer, I have: Name : RealPlayer Relocations: (not relocateable) Version : 7.0 Vendor: (none) Release : 7 Build Date: Wed 09 Aug 2000 11:54:59 PM EDT Install date: Sun 01 Oct 2000 05:33:22 PM EDT Build Host: two90 Group : Applications/Multimedia Source RPM: RealPlayer-7.0-7.src.rpmSize : 16412697 License: commercial Packager : pgodman@real.com I'd have to double check where I got this version of RealPlayer from, though.

Bill is this still a problem in the latest nightlies?

Marking NEW to get someone to look at it.

Moving to m0.9.1 and reassigning to serge.

Bill, could you provide url to linux realpayer download page? Thanks.

http://proforma.real.com/real/player/unix/unix.html This gets you version 8. This isn't the version I have/had, though; I was using version 7. I'll test some with version 8.

Still happens, with RealPlayer 8 and mozilla-0.8.1pre (buildid 200103222)

Thanks Bill, I'm able to reproduce the problem. I'm trying to figure how we can fix this using signal(),sig[set/long]jmp() calls.

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

Serge, can we just catch/ignore SIGPIPE and check return values for EPIPE value? BTW, what the difference between this bug and bug #59653? (I think RealPlayer is helper app, not plugin)

We can try to catch/ignore SIGPIPE but there is no way to distinguish where it comes from plugin or any other places. What we suppose to do with that signal if it comes, lets say, from X server? If you drop rpnp.so into plugins dir RealPlayer launches as a plugin.

Just do nothing with signal :-) Is it impossible to check read/write return codes for EPIPE (or whatever mozilla name for it) in every place we use pipes? There we'll exactly know from where it comes from and make decisions... BTW, what we're pipe into/from X server?

I dont know why I was thinking about X server, it is definitely not the right example:( BTW Denis, if you do have any proposals how to implement such kind of signal handler could you post it here, please?

No, I not making proposal yet. I just wonder why we can't just ignore the signal (not allowing default handler) - this will prevent us from crash. If we need SIGPIPE anyway, I don't see any way to handle it w/o direct support from NSPR. Stupid solution - make NSPR record pipe fd before any read/write to any pipe in some global var. Then value of this var at the time of SIGPIPE would be fd of pipe caused signal. I don't think this is very good idea, that's why I suggested to ignore SIGPIPE at all. But this will require us to check every pipe operation for EPIPE result.

Well, theoretically, we can walk up the stack from signal handler to find place from where signal was thrown. But I'm not sure if it's worth the trouble. We can also setup_signal_handler() do_plugin_stuff() reset_signal_handler() but this will not protect us from signals from other threads occuring while we're inside do_plugin_stuff(). So we probably have to survive pipe problems, but suffer other deadly signals...

completely agree, the implementation isn't trivial

Well, I think I know how to handle this for single-threaded program, but in case of multi-threaded programs I think this is impossible. The problem here is that you never know to what thread (among those not blocking signal) signal will be delivered. (Manually traking threads execution and swithing threads from signal handler doesn't worth the trouble, if even possible, IMHO). I think the best we can do in case of deadly signal (like SIGSEGV) is just exit()

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

(I'm moving here from bug 137132) Does anyone know how Konqueror handles this? They are somehow able to recover from errors from these same plugins.

shaver sez kongueror runs plugins in a separate process. /be

What is wrong with following Konquorer's lead? It seems to work. Moz already creates 9 threads. What's another few processes in the name of stability?

Sun's Java plugin on Linux and Adobe Acrobat on all platforms run in a seperate process. Neither plugin has fewer crashes than others. What about implementing nsPluginSaftey.h on Linux? Could the thread be marked that we're in the plugin's critical section?

There are two facets to following Konqueror's lead, and I think they will both bear fruit for us: - running Unix plugins in a separate process, with the right xid and proxying of appropriate plugin-host interface operations - handling the abnormal termination of those separate processes gracefully, which is where I think we currently fall down in the Java/Acrobat cases These are important stability issues for Mozilla, and I think it would be a good use of various plugin-expert cycles to investigate them. (Trying to play games with various signals and setjmp/longjmp while maintaining in-process plugins seems like a losing battle, to me, but I'm not one of the aforementioned plugin experts.)

> Sun's Java plugin on Linux and Adobe Acrobat on all platforms run in a seperate > process. Neither plugin has fewer crashes than others. As for Java, only JVM runs in separate process, but java plugin is usual a plugin :-) running in mozilla's address and it has dirty habit of exit()ing at almost any error :-((( I'm also curious, is there reasons *not* running plugins in separate process (i.e., why it's not made so from the beginning?). Except performance, of course :)

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

There is a good discussion about this on bug #58339 (trying to get #58339 marked as duplicate). I'm sure there are a _lot_ of bugs that should really be marked as a duplicate of this one. I'm trying to deal with the ones that I can find. Anyone else willing to help -- preferably someone who can actually make the changes?

Matt, to run plugins on separate thread wont safe mozilla from plugins which corrupt the heap memory, or as java plugin, call exit() on some error, or as flash, doing blocking device call... I completely agree with shaver, signals and setjmp/longjmp wont help for inproc plugins either. I confirm it. I've tried it. So, only separate process probably can help, but such implementation will definitely need some time and resources and should be started with investigation and prototyping. If you are willing to help us here, you are very welcome. Thanks.

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

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

Is this bug also about plugin crashing the browser? If not is there a bug filed for this? (I only foud one about a helper app crashing mozilla.)

1.2

*** This bug has been marked as a duplicate of 156493 ***

mass duplicate verifications . For filtering purposes, pls use keywd "massdupverification"