Mozilla crashes on launch with this Component Registry file

RESOLVED WORKSFORME

Status

()

Core
XPCOM
--
critical
RESOLVED WORKSFORME
17 years ago
10 years ago

People

(Reporter: Jonathan Brecher, Assigned: dougt)

Tracking

({crash})

Trunk
PowerPC
Mac System 9.x
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
Created attachment 66150 [details]
Component Registry file that causes a crash on launch

Updated

17 years ago
Severity: normal → critical
Keywords: crash

Comment 2

17 years ago
-> XPCOM Registry
Assignee: sgehani → dougt
Component: Preferences → XPCOM Registry
QA Contact: sairuh → dougt

Comment 3

16 years ago
Jonathan, is this problem still reproducible using a current build?

Comment 4

16 years ago
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.
(Reporter)

Comment 5

16 years ago
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.)

Comment 6

16 years ago
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

Comment 7

16 years ago
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

Comment 8

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

pi
(Reporter)

Comment 9

16 years ago
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.

Comment 10

16 years ago
So be it.

pi
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Updated

10 years ago
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.