The profile manager is using strings in the registry to store single bits of information, such as the migration state of a profile. nsProfile::GetProfileDir has a good example: // Get the value of entry "migrated" to check the nature of the profile m_reg->GetString( newKey, "migrated", &isMigrated); (isMigrated is never subsequently freed, as with a few other registry-returned strings in that function and others.) If you were to use integers for "migrated", you'd be able to avoid the memory management headaches and get a performance win to boot. To close this bug, you should: - ensure that you properly free all registry-returned strings - audit for excessive strdups (see 13298 for an example) - decide if you're going to switch to GetInt for the boolean attributes. (If not, please just note why not in this bug.) Thanks. Why not use an int

I don't see any functional reason to store this as a string in the registry.

I will change the migration status flag to an int and take care of other comments. Thanks. Changing status to assigned.

Putting on [Perf] radar.

These bugs are not critical for beta 1, moving out.

Bulk add of "perf" to new keyword field. This will replace the [PERF] we were using in the Status Summary field.

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

Moving this to M20.

Doing a mass reassign to Conrad Carlen. Conrad is going address all current and upcoming profile manager issues. Please do not hesitate to involve me in any of the issues.

With some work I did on nsProfileAccess.cpp recently, most of this has been fixed. The booleans were stored as strings in the registry but, worse, they were kept as strings on being internalized. There were many, many unicode string comparisons being done to test what should be only a single bit of data. My changes read the string once, disposed of it, and stored it as a PRBool. I kept it as a string in the registry itself to avoid compatibility problems.

verified code fix