Closed Bug 121475 Opened 23 years ago Closed 22 years ago

Mozilla crashes on launch with this Component Registry file

Categories

(Core :: XPCOM, defect)

PowerPC
Mac System 9.x
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jsb, Assigned: dougt)

Details

(Keywords: crash)

Attachments

(1 file)

With the attached Component Registry file present in mozilla/dist/viewer_debg, 
Mozilla crashes on launch.  Deleting the file causes it to be regenerated by 
Mozilla, at which point everything is fine.

I'm running a debug build of mozilla, with sources pulled ~10pm last night.  The 
end of the call stack reads:

nsPrefServiceConstructor()
nsPrefService::Release()
nsPrefService::~nsPrefService()
PREF_Cleanup
PREF_CleanupPrefs
PrefNameBuffer::FreeAllBuffers()
...and then six more boring functions within NSStdLib associated with the 
"delete curr" call in PrefNameBuffer::FreeAllBuffers().

It's *possible* that this is a duplicate of bug 117103, but I've been trying to 
get my plugin to work and it's more likely that I simply managed to corrupt the 
Component Registry file in a new-and-interesting way.
Severity: normal → critical
Keywords: crash
-> XPCOM Registry
Assignee: sgehani → dougt
Component: Preferences → XPCOM Registry
QA Contact: sairuh → dougt
Jonathan, is this problem still reproducible using a current build?
Any relation here to bug 72518? It's the only other "corrupt registry" bug I could find.

Mozilla certainly shouldn't crash if the registry is corrupt.
Sorry, but we're totally blocked by the outstanding bugs 119586 and 120822.  
Considering how long and painful each Mozilla build is, I'm not even going to try 
to confirm with the latest build until there's some prospect of our being able to 
do further development.  (Besides, the short answer is that if you can't 
reproduce the crash using the attached file, then I probably can't either.)
Greg K:

I have a confirmation of a crash (well a "quit without any error message") on
launch for current builds from the FTP site.  I don't do my own.  But builds
from the last week or so have had this problem ... specifically the Mac OS 9
builds, but NOT the CFM Mac OS X builds.  I can normally run either of these in
Mac OS 9, but when the problem appeared I could no longer run the Mac OS 9 spins.

Then yesterday I got the hint to delete the Component Registry created during
installation and/or create a new profile.  I have found that deleting the
Component Registry is the key ... with or without a new profile.  I was then
able to run the 20020617 and 20020618 builds.

Systems used:
6400 w/ Mac OS 9.1 & 72 MEgs
iMac w/ Mac OS 9.2.2 & 320 Megs

Later ...
                Dale
Testing Mac OS Build ID 2002061908, I found that the problem with the Component
Registry has gone away.  It was not necessary to delete the Component Registry
created by the installer as it had been for the last few days or a week.  The
problem existed in 6/17 and 6/18 builds and is gone in the later 6/19 build.  I
didn't test the earlier 6/19 build.

Dale
Jonathan, according to Dale it works now. How about you? Please resolve as
WORKSFORME if you cannot reproduce the problem anymore.

pi
I cannot confirm or even test the status of this bug.  We have shut down all 
development related to Mozilla until there is some prospect of getting a plugin 
that might work.  I would be happy to retest this once we are un-blocked (Bug 
119586), but otherwise we have decided to focus our efforts on working with 
companies that want to be worked with.

Mark this bug however you want; I don't care.
So be it.

pi
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Component: XPCOM Registry → XPCOM
QA Contact: doug.turner → xpcom
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: