Closed Bug 36272 Opened 24 years ago Closed 23 years ago

RFE: Crash (SIGSEGV) in plugin code should be catched...

Categories

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

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

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: roland.mainz, Unassigned)

References

Details

(Keywords: helpwanted) 

I don't know if this is possible on all platforms, but...
RFE: A SIGSEGV etc. (e.g. crash) on plugin-code should be catched instead of
crashing the whole browser.

Any suggestions how to implement this (on WinXX??, Unix) ? How does GDB do the
trick ?
Adding crash keyword.
Keywords: crash
This bug is not about specific crash. I am not sure the crash keyword is 
appropriate here.
Status: NEW → ASSIGNED
Target Milestone: --- → M19
Well... the browser crashes due malicious foreign plugins... and there may be a
fix for this, right ?
Eliminating crash keyword; it's inappropriate here as it's only used to mark 
specific crashers for high priority fix.

I doubt this is even technically possible; how is one native binary (the 
browser) supposed to intercept a crash occurring within another native binary 
(the plugin)? Marking FUTURE and helpwanted and reassigning to 
nobody@mozilla.org.
Assignee: av → nobody
Status: ASSIGNED → NEW
Keywords: crash → helpwanted
Target Milestone: M19 → Future
Both GDB and /usr/dt/bin/dtlogin (CDE's version of xdm) seems to support this...
Adding crash to keyword field.
Keywords: crash
On Unix-like systems, you could arrange to catch SIGSEGV and SIGBUS (maybe even
SIGILL?), but you'd be making a wish that the bad address that crashed the
plugin didn't indicate worse corruption that would soon crash the browser.  And
you would want to keep track, and put the plugin on a sick-list, to be avoided
after more than a few (if not after the first) crashes.

/be
gdb (and, I suspect, dtlogin) are dealing with different processes, and plugins
run in-process for us.  I'm removing the |crash| keyword, because there's no
specific crash referenced, and a crash in a plugin is like a crash due to a bug
in GTK: there's not much we can do to prevent it.

(I'm tempted to WONTFIX it, but if nothing else we should get it off the crash
triage radar.)
Keywords: crash
*** Bug 90437 has been marked as a duplicate of this bug. ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Looks like after long talks and discussions with many people we have nofix here.
*** Bug 94532 has been marked as a duplicate of this bug. ***
IE5/6 supports this "feature". Why can't we do the same ?
There's no way to recover safely from an arbitrary memory error on Unix, that I
know of.  How would you have us solve this problem?  How does IE 5/6, that you
would have us take as proof of this "feature"'s viability, solve this problem?
(I've had bad ActiveX take out IE 5 and 6 on me, so I think you're unclear on
the situation, but I'll give you the benefit of the doubt.)

I'm slightly confused by this bug which is resolved ALL/ALL WONTFIX.  I seem to
recall using mozilla recently on w32 and having a plugin crash, mozilla told me
about it and i then went about my business.

The discussion here seems to be Unix [x11] oriented as such i think we should
change it to PC:Linux.  Can anyone point to the magic that made PC:Windows98 do
something else? Or was i halucinating?
v
Status: RESOLVED → VERIFIED
Depends on: 115903
No longer depends on: 115903
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.