Closed
Bug 121475
Opened 23 years ago
Closed 22 years ago
Mozilla crashes on launch with this Component Registry file
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jsb, Assigned: dougt)
Details
(Keywords: crash)
Attachments
(1 file)
157.71 KB,
application/octet-stream
|
Details |
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•23 years ago
|
||
Comment 2•23 years ago
|
||
-> 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.
Reporter | ||
Comment 5•22 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.)
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
Comment 8•22 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•22 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•22 years ago
|
||
So be it. pi
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•