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)

x86
Linux

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 28243

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
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
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.
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.
Thanks for letting me know.
ok
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.