154054 - Profile registry gets corrupted on core dump

Status: VERIFIED DUPLICATE of bug 153562

(Core Graveyard :: Profile: BackEnd, defect)

Description

[km]

I'm seeing this on 

Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1a+) Gecko/20020624
Sparc/Solaris

After a mozilla core dump, on the next start up the profile manager says
that the directory containing the profile does not exist. From truss
I see

access("�/homes/km/.mozilla/default/9rp7jeu7.sl", 0) Err#2 ENOENT

which make it seem that the string containing the directory name has been
corrupted by one byte (extraneous character on left, missing t on right).

This is consistant with a thread on comp.sys.sun.apps

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF8&th=1cb8f98fbb756163&rnum=1

where others have seen this too.

Comment 1

[Jim Crumley]

Confirming based on news group posts mentioned.  I haven't seen this myselef on
recent Solaris nightly builds running on Solaris 7. If there any common factor
to the crashes that precede the corruption?  Does the corruption occur any time
a crash occurs?

Comment 2

[Andrew Hagen]

Bug 98476, now resolved fixed, is supposed to have fixed this problem. Maybe
this bug is a regression?

Comment 3

[Conrad Carlen (not reading bugmail)]

Changing the summary to what I think is more accurate. It's not the profile
itself that's corrupted but the registry which lists the profiles and their
respective dirs. Need to see when the profile mgr is flushing out the registry
to disk and how this could happen...

CC'ing dveditz for his registry insight.

Comment 4

[Daniel Veditz [:dveditz]]

Last time I looked (which was before the plugin guys started using the registry)
the profile code opened and closed the registry at each operation. Slower, but
guarantees flushing. The registry is ref counted, but a call to close will cause
a flush even if the file isn't physically closed at that point.

The plugin registering code might not be closing the registry when they're done
with it.

Comment 5

[Daniel Veditz [:dveditz]]

The plugin code never explicitly closes the registry, but they've instantiated
it using a nsCOMPtr and Close gets called when the nsRegistry object is
destroyed. Is there a nsRegistry object leaking somewhere?

Comment 6

[R.K.Aa.]

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

Comment 7

[Calum Mackay]

We're also seeing this on occasion when mozilla has been shut down cleanly, no
core dump. Started a week or so ago.

Comment 8

[Jürgen Keil]

This is a duplicate entry of 153562, see

   http://bugzilla.mozilla.org/show_bug.cgi?id=153562

153562 has an analysis of the problem and a proposed patch.

Comment 9

[Jim Crumley]

*** This bug has been marked as a duplicate of 153562 ***

Comment 10

[K'Trina Medina]

Verified as a dupe of bug 153562