16209 - [DOGFOOD]M9 mozregistry.dat crashes with M10; registry format changed

Status: VERIFIED FIXED

(Core Graveyard :: Profile: BackEnd, defect, P3)

Description

[selmer (gone)]

The pathnames we write into the registry were changed into a platform
independent format during M10, but nothing was done to upgrade existing registry
files or at least delete them during the install or something.

We need to add versioning to the profile registry so we can avoid this class of
problems in the future.  A simple mechanism is to add a version key under the
toplevel profile key.  If the version key is not there, then the registry is bad
and something should be done to fix it (delete or rewrite.)  If the version is
there, it should be compared to the current code's version and again appropriate
action should be taken on a mismatch.

Comment 1

[Eli Goldberg]

*** Bug 16207 has been marked as a duplicate of this bug. ***

Comment 2

[racham]

Chris Yeah told me that the M10 bits are out and there is no plan to respin with
any additional fixes. The problem is caused due to the incompatabilty of the way
profile directory name entries are stored in the (moz)registry. The work around
(i.e., deleting mozregistry.dat) is posted in the news groups. I'm working on
the fix that fixes these incompatible strings (instead of crude deletion
of mozregistry) so that we won't run into this problem again with M9 (< M9)
users when they get M11 (>= M10) bits. Changing the severity to major.

Comment 3

[Paul MacQuiddy]

*** Bug 15398 has been marked as a duplicate of this bug. ***

Comment 4

[racham]

*** Bug 14684 has been marked as a duplicate of this bug. ***

Comment 5

[selmer (gone)]

Dogfood Candidate

Comment 6

[daver]

this is a beta bug

Comment 7

[selmer (gone)]

The consequences of this problem in M10 were pretty severe.  This work is
basically done, we're just doing unit testing on the Mac before checking it in.
If there's to be a public M11 build, you want this fix in it.

Comment 8

[Jim Roskind]

The following comment came from DP, and I copied it here.  I also took away
the PDT- so that the PDT would reconsider.

The bug caused a ton of coredumps on XPCOM to be filed. Most of them
turned out to be "Ah! delete your mozregistry.dat" 1 or 2 turned out to
be real bugs.

If this happens again, I am afraid we could lose real bugs in the noise. Any
M9 -> later than M9 will cause the crash.

Selmer, already has raised it in the bug.

Comment 9

[Jim Roskind]

We're PDT+ to stop the upgrade nightmare to dogfood

Comment 10

[racham]

Checked in Fix. The length of the dir path gets prepended to the path in hex
format in mozregistry of M9 and in prior versions. This code goes into the old
registry fixes the M9-style (<M9 versions) paths of the directory names to the
current format. For the existing registry (M10 and after), the registry entries
will be unchanged.

Testing :

Case 1 : Get M9 build. Wipe out the existing registry. Create a profile. Now you
have the mozregistry. Run the latest build. Mozilla browser should come up just
fine wihtout any problems (crahses or hang).

Case 2 : Get M10 build. Wipe out the existing registry. Create a profile. Now
you have the mozregistry. Run the latest build. Mozilla browser should come up
just fine wihtout any problems (crahses or hang).

Case 3 : Get any build prior to 10/22 (but > M10). If you have a registry just
leave it alone. Get the latest build. Run the mozilla. You should be able to go
into the browser without any problems. This guarantees no fixing operations are
done on the registry.

Comment 11

[Suresh Duddi (gone)]

What ? length of the dir path. Why not a version number that is #ifdeffed in the
code.

#define NS_MOZ_REGISTRY_VERSION "bhuvan1.0"

openmozreg()
{
	registry->GetString(key, versionAttribute, &version);
	if (strcmp(version, NS_MOZ_REGISTRY_VERSION))
	{
		// Delete the profile hiearchy and do require init.
	}
}

Putting length of registry data path name seems wrong.

Comment 12

[racham]

I'm sorry. The explaination I gave in the bug report misled you to in
understaning the fix I checked. After I wrote Checked in Fix, I started
explaining the problem we had with M9 builds. I shouldn't have done that.

The actual fix is in line with what you mentioned. The difference is that we
fix the registry entries, instead of deleting the whole registry. Here is the
description of the checkin.

92 #define REGISTRY_VERSION_1_0  "1.0"  // registry version number.

in profile Startup()
{
.
.
194     nsXPIDLCString versionKey;
195     rv = m_reg->GetString(key, REGISTRY_VERSION_STRING,
getter_Copies(versionKey));
196
197     if (versionKey == nsnull)
198     {
199         FixRegEntries(); //Fixes all entries that have hex bytes in path.
200     }
201
202     rv = m_reg->SetString(key, REGISTRY_VERSION_STRING,
REGISTRY_VERSION_1_0);
.
.
}

FixRegEntries() deletes the number of bytes prepended (resulted with <= M9
builds)in the path and makes it a regular path that can be used by the current
builds.

Comment 13

[Grace Bush]

tested as described without problems (crashes or hangs)
marking verified on build 1999102110

Comment 14

[leger]

Moving all Profile Manager bugs to new Profile Manager Backend component.
Profile Manager component to be deleted.