Closed Bug 17157 Opened 25 years ago Closed 23 years ago

apprunner crashes after libgfx_gtk.so has been deleted...

Categories

(Core :: XPCOM, defect, P3)

Product:
Core
Component:
XPCOM
Platform:
All
Linux
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: roland.mainz, Assigned: dougt)

Details

(Keywords: crash) 

M10 apprunner on Solaris/Linux crashes after libgfx_gtk.so has been deleted.
Seems that the Zilla has problems with detection of missing libraries.
IMHO startup should check this and fail with a message - instead of dropping a
core dump.
Assignee: don → mcafee
QA Contact: leger → elig
mcafee, might ya know where to put this? (Don't see any obvious existing bugs
querying for 'library' or 'delete')
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
I don't care about this bug, marking won't fix.
Don't delete the library.  We've got way too much
other stuff to fix right now.  You are welcome to
submit a fix for this.
Aehm, the problem may also occur if something does wrong with the build
(deleting it maually is only one way to create the problem, another problem may
be NFS server failure (soft mounts), dumb admins playing with file permissions
etc.).
It would be really nice if apprunner contains a simple "hack" which checks if
the matching libraries are available (incl. the right permissions) or not
(stat() !?).
Status: RESOLVED → REOPENED
ok will take another look, reopening
Resolution: WONTFIX → ---
Target Milestone: M13
Assignee: mcafee → dp
Status: REOPENED → NEW
Component: Browser-General → XPCOM Registry
xpcom, over to dp for a look.
Severity: critical → normal
Status: NEW → ASSIGNED
Target Milestone: M13 → M16
Downgrading to normal. Common this is a wierd error case. There could be so
many things that might go wrong if some .so fails to load. We need to test many
of those error cases.
Adding "crash" keyword to all known open crasher bugs.
Keywords: crash
Target Milestone: M16 → M20
Moving all current open XPCOM and XPCOM Registry bugs to rayw since dp is on 
sabbatical.  rayw is now default assignee for these components.
Assignee: dp → rayw
Status: ASSIGNED → NEW
One of a bunch of bugs related to "registering components in XPCOM".

Without autoregistration, I believe that the observed behavior is the 
expected/desired behavior.  But I don't desire this sort of behavior, which is 
why I would like an advanced component-path-based behavior.
Status: NEW → ASSIGNED
Updating QA Contact
QA Contact: elig → tpreston
Edward: Welcome to xpcom!
Status: ASSIGNED → NEW
Component: XPCOM Registry → XPCOM
QA Contact: tpreston → rayw
Target Milestone: M20 → mozilla1.0
Once again... attempting to reassign from Ray to Edward.
Assignee: rayw → kandrot
Status: NEW → ASSIGNED
reassign all kandrot xpcom bug.
Assignee: kandrot → dougt
Status: ASSIGNED → NEW
Target Milestone: mozilla1.0 → ---
this is a library linked directly to the application. deleting it has nothing to
do with the stablity of xpcom.  Marking as invalid.
Status: NEW → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.