59653 - Avoid browser crash when helper app crashes

Status: VERIFIED DUPLICATE of bug 156493

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

Description

[Akkana Peck]

Someone said "RHEEEEEEET" in chatzilla, and I clicked on it.  Mozilla crashed.

I'm on RH 7.0.  I have xmms set as my audio/wav handler (which worked in RH
6.2).  On this machine, I haven't yet run sndconfig, I do have xmms (v. 1.2.2)
but when I run it manually, of course it doesn't play any sound (since the sound
card isn't enabled), and when I exit, xmms crashes.

Nevertheless, seems like mozilla shouldn't crash even if a plugin does, so I'm
filing this.

Comment 1

[Braden]

As long as the plugin instance and the browser instance share the same process,
I'm not so sure a crash can be avoided in this case. Look at bug 36272, though.
Is this a duplicate?

Comment 2

[karnaze (gone)]

Moving to mozilla0.9

Comment 3

[Peter Lubczynski]

How about using signal handlers

http://www.calpoly.edu/cgi-bin/man-cgi?sigvector+2

Stealing away from av unless he objects.....

Comment 4

[Peter Lubczynski]

Swapping 0.9 bugs

Comment 5

[karnaze (gone)]

Moving to m1.0

Comment 6

[Arun Ranganathan]

nominating nsbeta1 based on peterl's comments to my pdt bug list.  cc'ing serge
-- any ideas, serge?

Comment 7

[Arun Ranganathan]

Here are peterl's suggestions:
"This can be done with using signal handlers. Perhaps Serge is up to it.
Implement something sort of like pluginsaftey.h to catch when a plugin crashes."
peterl, update info. on sig. handlers.

Comment 8

[serge (gone)]

I have 62460 which is a dup of this one.
Unfortunately unix sigsetjmp()/siglongjmp() are not equal to try/catch pair 
implemented in pluginsaftey.h. It's straightforward to use those calls  for 
a simple lineal code. In our case we have to invent some sophisticated algorithm 
to distinguish what part of the code delivers a given signal for a process.
Let's consider the next scenario:
before plugin's calls we do:
signal(SEGV, our_sig_handler); if(sigsetjmp()){CODE_AFTER_LONGJMP:...} 
...
then we open new window without any plugins, but something goes wrong and we get 
SEGV, our_sig_handler() is called and with simple implementation we do 
siglongjmp() to CODE_AFTER_LONGJMP label, which is totally wrong, and eventually 
we'll end up with complete chaos.
So it looks there is no easy way to setup signal handler per separate 
component:(

Comment 9

[Peter Lubczynski]

Serge,

Would it be possible to push the state of the signal handler before making the 
call to the plugin then popping the state right after the call? Wouldn't that 
make the signal handler only active for a brief instant, the scope of the plugin 
call?

Comment 10

[karnaze (gone)]

serge, if you cannot get to this, please reassign to dr. 

Comment 11

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Is akkana really talking about a plugin here, or a helper app?  I didn't know
you could plug xmms into Mozilla.  (And we _definitely_ shouldn't crash when a
helper app bails.)

Comment 12

[Akkana Peck]

Helper app is more accurate.  Changing summary accordingly.

Comment 13

[serge (gone)]

moving forward tm

Comment 14

[Denis Antrushin]

Doesn't we just fork off helper app passing temp filename to it as argument?
If so, how we can depend on helper app (assuming we fork/exec cleanly)?

Comment 15

[rubydoo123]

part of the separation of plug-ins into unique process

Comment 16

[rubydoo123]

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

Comment 17

[shrirang khanzode]

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