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 ***

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