Closed Bug 151000 Opened 22 years ago Closed 11 years ago

profiles disappear from the profile manager

Categories

(Core Graveyard :: Profile: BackEnd, defect)

Product:
Core Graveyard
Component:
Profile: BackEnd
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE
Milestone:
mozilla1.5alpha

People

(Reporter: bugzilla, Unassigned)

References

Details

(4 keywords) 

i've been experiencing this for some time, and unfortunately i cannot seem to
figure out the exact steps of what would cause this. basic issue: i test with
multiple profiles, but after a while, some of the profiles (the most recently
created ones) disappear from the profile manager window. strangely, the profile
directories themselves in ~/.mozilla exist --but, sadly, even when i try to
launch  a specific profile with -P, that profile is not launched (i get the
profile mgr window, as if that profile didn't exist).

so far i've only seen this on linux rh7.2. i have yet to encounter it on win2k
or mac OS X 10.1.x, so far...

basic recipe:

0. start out with no profiles (ie, moved my existing ~/.mozilla to another name).

1. created 1st profile --it's called "se". i did this with a branch build;
unfortunately, i cannot remember if i was using the 7.0-pr1 build or the
2002.06.10.07 branch (still commercial) build (sorry). i copied over my
bookmarks.html from the older profile in step (0), and after i created my
regular email account, i also copied over the rules.dat and modified prefs.js to
include my custom header info. (i know, this might not be relevant, but thought
i cannot hurt to add here, while i'm remembering.)

2. created 2nd profile --called "branch1". again, not sure if i used 7.0-pr1 or
y'day's branch build. didn't do any funny copying business with this one as i
had with "se".

3. created 3rd profile --called "trunk1". created this using the
2002.06.10.08-trunk commercial build.

4. proceeded with my usual testing for yesterday, which involves going btwn
branch and trunk builds, restarting builds several times, etc... (note: i did
not attempt to launch the same profile with different builds or another instance
of the same build --grace mentioned that that has been recently prevented anyhow.)
  * during this time i encountered (but canceled out of) activation for those
three profiles.
  * also, i almost always had my "se" profile running (with a branch build) so
that i could quickly check email, the tree, etc.
  * the three profiles always showed up in the profile mgr window.

5. at the end of the day, i quit all instances/builds of netscape.

6. today, i tried launching the profile manager with y'day's trunk build...and
noticed that "trunk1" was no longer listed. using "./netscape -P trunk1" didn't
work...nor did launching using y'day's branch build.

any idea what might be going on here?

i've been using the wizard to create the profiles, if that's meaningful.

i noticed that activation is different btwn trunk and branch builds, could that
have anything to do with it? grace says that's unlikely, however...

pls let me know if there are other steps/things i could check out here. would
attaching my appreg file (currently just under 15k in size) help?
made this critical since it basically hoses the multi-profile situation that i
frequently need for daily testing...
I've seen this on Windows 98. I created a profile with a long, complicated name
and entered it. I changed the theme. Then I made many other Preferences changes.
Then I exited. When I started Mozilla again, it wasn't listed in profile
manager. I renamed registry.dat (I still have the old 1.9MB one), and started over.
OS: Linux → All
when i came in this morning and started up a trunk build (fwiw, the same
2002.06.10.08 one), the 2nd profile was missing. moreover, now that there was
only "one" profile ("se"), the profile mgr window still appeared (listing "se")
--should it not appear when it thinks there's only one profile?

just spoke with grace: she mentions that *mebbe* the fix for bug 12911 might
have affected this situation?

also, i'm logged one with a local linux account (eg, /home/halo), *not* my
network mounted account. would this have an affect?

i'm pretty concerned about if/when my "se" profile will "disappear" --recreating
test profiles is okay, but having to recreate my primary work profile frequently
would be Real Pain.

pls let me if there are possible workarounds or steps you'd like me to try out
that might alleviate this. thanks!
Are the profiles on your system anywhere in the file directory?
the profile directories themselves, interestingly, still exist in the ~/.mozilla
dir. it's as if references to them have gone poof (since -P doesn't work).
grace pointed me to the appreg tool at
http://slip.mcom.com/softupdate/BiggerRegToy.html, and the tree dump is below.
unfortunately, it only shows info for my remaining profile "se" (the 1st one i
created, my workhorse), and "test2", which i just created this morning (using
-CreateProfile, fwiw).

Registry opened
Subtree Dump of /
--------------------------------
Users
Common
Common/Profiles
    CurrentProfile (S)=test2
    HavePregInfo (S)=
    Version (S)=1.0
Common/Profiles/se
    directory (S)=/home/halo/.mozilla/se/0lz1m8g5.slt
    LastModTime (B)=]\0xe7\0x8da\0xee\0x00\0x00\0x00
    CreationTime (B)=\0xd5\0xb6\0x94[\0xee\0x00\0x00\0x00
    NCHavePregInfo (S)=yes
    NCEmailAddress (S)=
    NCServiceDenial (S)=yes
    NCProfileName (S)=
    migrated (S)=yes
Common/Profiles/test2
    directory (S)=/home/halo/.mozilla/test2/1og55ydb.slt
    LastModTime (B)=}WAe\0xee\0x00\0x00\0x00
    CreationTime (B)=\0xf4\0xc3/e\0xee\0x00\0x00\0x00
    NCHavePregInfo (S)=yes
    NCEmailAddress (S)=
    NCServiceDenial (S)=1
    NCProfileName (S)=
    migrated (S)=yes
Common/software
Common/software/plugins
    version (S)=0.04
Common/software/plugins/plugin-1
    canUnload (I)=:1:
    lastModTimeStamp (B)=\0xa0|\0xe4Z\0xee\0x00\0x00\0x00
    description (B)=The default plugin handles plugin data for mimetypes and
extensions that are not specified and facilitates downloading of new plugins.\0x00
    name (B)=Default Plugin\0x00
    filename (S)=/export/builds/2002061007-br/plugins/libnullplugin.so
Common/software/plugins/plugin-1/mimetype-0
    extension (S)=.*
    description (B)=All types\0x00
    mimetype (S)=*
Common/software/plugins/plugin-2
    canUnload (I)=:1:
    lastModTimeStamp (B)=\0x00g\0xe5Z\0xee\0x00\0x00\0x00
    description (B)=Shockwave Flash 5.0 r48\0x00
    name (B)=Shockwave Flash\0x00
    filename (S)=/export/builds/2002061007-br/plugins/libflashplayer.so
Common/software/plugins/plugin-2/mimetype-0
    extension (S)=swf
    description (B)=Shockwave Flash\0x00
    mimetype (S)=application/x-shockwave-flash
Common/software/plugins/plugin-2/mimetype-1
    extension (S)=spl
    description (B)=FutureSplash Player\0x00
    mimetype (S)=application/futuresplash
Version Registry
Private Arenas
--------------------------------
Keywords: dataloss
i think i've found a simple test case for this. i don't have a recent branch
build (currently at home), but this still occurs with the public beta release
--will test again tomorrow.

it looks like the clobbering is due to having multiple instances of the *same
build*. i had thought that linux (unix in general) allows multiple instances of
the same executable to run (unlike Mac or Win32). was there something that
changed in mozilla (and/or netscape) which now precludes this? this has not been
a problem for me before...or, so i thought. i could be misunderstanding how
linux treats multiple instances!

anyhow, the recipe:

0. start out clean by renaming ~/.mozilla

1. create a new profile: i launched the executable as "./netscape
-ProfileManager" and went thru the wizard from there. eg, call this profile "a",
and launch it.

2. quit and relaunch with "./netscape -ProfileManager" to make sure "a" exists.

3. keep "a" running with this first instance. (you'll want to always have it up
until step #7.)

4. launch another instance of the same build --again i did "./netscape
-ProfileManager" and create profile "b". launch "b" from this second instance.

5. quit the second instance, and relaunch with "./netscape -ProfileManager" to
also make sure "b" exists.

6. quit profile "b".

7. quit the first instance that's running profile "a". you should now have *no*
instances of the same build running.

8. relaunch ("./netscape -ProfileManager") the build.

result: only "a" is displayed.

expected: both "a" and "b" should be visible in the profile manager.
Keywords: nsbeta1
i can repro this using mozilla 1.0.

moreover, i tried a variation on the test case in comment 7: essentially the
same recipe except that the second profile "b" would be created and launched
using another build. eg, "a" used the 2002.06.12.07-branch build and "b" used
the 2002.06.13.07-branch build.

the result is that i still encounter the bug. :( i can work around running the
same builds at the same time (diff profiles, o'course), but clobbering profiles
when running different builds would block a lot of my testing work. (in which
case i'd consider this a serious regression from previous experience...)
Keywords: regression
> but clobbering profiles when running different builds would block a lot of my
> testing work. (in which case i'd consider this a serious regression from
> previous experience...)

It's a syncronization problem of data in the registry. If you're adding and
removing data from the same file by two different instances, this can happen.
Though, since we've never protected the registry from simultaneous access by
multiple instances, I'm curious as to how this could be a regression. Are you
sure this doesn't happen with 2 builds from several months ago?
i tried the recipe in comment 7 using two builds from early March (2002.03.05.11
and 2002.03.06.07), and i did not encounter this problem. i double-check,
though, and see if i can narrow down when this might've started occurring.

another test i did (a potential workaround): make sure that another instance of
netscape (or mozilla) is *not* running when creating another profile. in other
words, quit profile "a", then create "b" with a new instance of the app. after
that, i can run multiple instances (again, different profiles, but the same or
different builds are okay) without losing profiles. (so far --i imagine there
could be several permutations of this. ;)
looks like this regressed btwn 5/2 and 5/3. when tested this using
2002.05.02.09-1.0.0 bits, this is not a problem. however, i encounter this bug
when using 2002.05.03.09-1.0.0 bits.
bumping down a bit, since i've got a workaround.
Severity: critical → major
Blocks: profile-corrupt
Keywords: relnote
This happens on Mac OS X too.
Hardware: PC → All
*** Bug 175919 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.3alpha
*** Bug 177784 has been marked as a duplicate of this bug. ***
*** Bug 178709 has been marked as a duplicate of this bug. ***
I experienced this by accidentally deleting Application Registry file.
I have not been able to get Mozilla to recognized the old profiles any more.
2003010808 trunk for MacOS9.x
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: major → critical
QA Contact: ktrina → gbush
*** Bug 192097 has been marked as a duplicate of this bug. ***
This can be fixed with much more certainty when profile mgr stops using
nsIRegistry to maintain the profile list. The registry may be caching file
handles - keeping them open longer than client code expects and can control.
Depends on: 174522
conrad: is there any easy way to recover a profile once the registry file has
been overwritten?
darin: if you create a new profile with the same name as the one that's
orphaned, and, for the new profile, choose the same parent dir as the orphaned
profile dir, it should use the existing folder. 
Mass move of 1.3a bugs -> 1.4a.
Target Milestone: mozilla1.3alpha → mozilla1.4alpha
-> 1.5a
Target Milestone: mozilla1.4alpha → mozilla1.5alpha
*** Bug 200992 has been marked as a duplicate of this bug. ***
*** Bug 201010 has been marked as a duplicate of this bug. ***
My Mozilla is still suffering from this bug, however I've just noticed that 
Mozilla doesn't stay in memory (i.e. Quick Launch) either, even after choosing 
the option in the Preferences screen.




I choose the option "Keep Mozilla in memory...", then close Mozilla. As it's 
closing, a warning window pops up to say that Mozilla will be kept in memory, 
and will live in the System Tray, etc... but when I click "OK" in that window, 
Mozilla dies, System Icon and all. I can reproduce this every time on Windows 
2000 with Mozilla 1.3 final.

adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
This sounds like what I'm experiencing with the latest release.  I create a new
profile & everything is fine til I close Moz.  When I reopen it it grabs the NS
7.02 profile & changes all the preferences.  The new profile is not visible in
Profile Manager even though it is in the ~/mozilla/profile directory.
This is on a WinXP machine.
Reproduced on Debian GNU/Linux 3.0
Mozilla 1.4
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4) Gecko/20030624
uname -a=Linux ork 2.4.18-k6 #1 Sun Apr 14 12:43:22 EST 2002 i586 unknown

installed mozilla from .tar.gz
*** Bug 220731 has been marked as a duplicate of this bug. ***
*** Bug 232451 has been marked as a duplicate of this bug. ***
(In reply to comment #7)
> i think i've found a simple test case for this.

I seem to have found an easier test case yet. The problem I see is totally
independent of multiple builds, for I only use one build
(Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803). Here are the
steps:
1. rm -rf .mozilla .netscape*
2. mozilla &
3. mozilla  -> dialog appears. create new profile "test" and "run mozilla"
4. quit mozilla session of "test", and _then_ the default session. This is
important, if I do it the other way around, I don't see the bug!
5. ll ~/.mozilla contains a folder named "test". appreg matches the string "test"
6. mozilla -ProfileManager  -> dialog only shows "default"
   mozilla -P test -> opens dialog, does not find profile "test"

*** Bug 288593 has been marked as a duplicate of this bug. ***
does this really depend on bug 174522 or is 174522 just "nice" to do before this one?
Assignee: ccarlen → nobody
Status: ASSIGNED → NEW
Keywords: testcase
QA Contact: agracebush → profile-manager-backend
This was against the old profile code which hasn't existed since the switch to Firefox.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.