Closed Bug 36272 Opened 25 years ago Closed 24 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: 24 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.