Closed
Bug 29221
Opened 24 years ago
Closed 24 years ago
first attempt to create new profile fails
Categories
(Core Graveyard :: Profile: BackEnd, defect, P3)
Tracking
(Not tracked)
People
(Reporter: dbaron, Assigned: selmer)
Details
DESCRIPTION: I removed my ~/.mozilla directory to create a new profile, because my old one had lots of junk in it that was messing things up. I started the profile manager, created a profile, and then mozilla started up, but was using 100% CPU until I exited. The ~/.mozilla/ directory and ~/.mozilla/registry and the files in ~/.mozilla/David/ looked like they were created correctly. However, when I started up again, it asked me to create a new profile again. The second time, it worked. It did not use 100% CPU, and the cofiguration was reused later. However, it created a directory ~/.mozilla/David-1/, and the ~/.mozilla/David/ directory was lying around unused. (I went through these steps twice, to make sure they were reliably reproducable. They are.) STEPS TO REPRODUCE: 1) move ~/.mozilla/ to a different location (e.g., ~/.mozbak/) 2) launch mozilla 3) create a new profile by typing in a name, hitting next and finish (or whatever it is...) 4) exit mozilla 5) launch mozilla again ACTUAL RESULTS: * after step 3), Mozilla uses up 100% of the CPU until step (4). * after (5), Mozilla askes to create a new profile again, and it is the profile created the second time that is used. The first profile created just wastes space on the disk EXPECTED RESULTS: * normal CPU usage * only one profile is created and used DOES NOT WORK CORRECTLY ON: * Linux, mozilla, 2000-02-24-15-M14
Assignee | ||
Comment 1•24 years ago
|
||
All known profile data loss problems result from the registry problem described in 28243. *** This bug has been marked as a duplicate of 28243 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 2•24 years ago
|
||
Is that bug marked beta1? I don't have permissions to see it (it's Netscape-internal). If not, could you mark it beta1 and refer to this bug.
Assignee | ||
Comment 3•24 years ago
|
||
I'm not convinced 28243 needs to be internal only, but it'll be closed today or Monday anyway. It is currently PDT+ and has a couple other bugs duped against it because the registry problem has many side-effects. The gist of the problem is that the libreg library was being statically linked into 2 places, but it depends on having a single global data area. This causes the two consumers to conflict with each other and only one wins. Luckily, it's a one-line fix in the xpinstall makefile to eliminate the second static library.
Reporter | ||
Comment 4•24 years ago
|
||
Thanks for letting me know.
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•