119941 - Profile may become corrupted

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Geoff Elliott]

After a few days of using 0.9.7 I began experiencing severe problems with the
browser.  When visiting numerous pages (news.com, www.onepointzero.com) the
style sheet would not load until I did a shift-reload; when trying to visit
other pages (bugzilla.mozilla.org for example) I was informed that the file "/"
could not be found, but these sites loaded fine in other browsers (including
Netscape 6.2); and site icons were no longer displayed in the address field,
personal toolbar or bookmarks tree, instead the spot was blank.

Creating a new profile fixed these problems.  I recreated my bookmarks by
copying and pasting from bookmarks.html and set my preferences.  And for a few
days I had no problems.

This morning the same issues started again.  First sign was the icons
disappearing, then pages refused to load, now style sheets won't load the first
time either.  Once again, if I create a new profile everything behaves.

I'm not sure exactly how to file this as it doesn't seem to fit under Profile
Migration and I'm unsure if it really has anything to do with the Profile
Manager.  If I can be of any help with more specifics, or profile files, please
let me know.

Comment 1

[Geoff Elliott]

Also unsure if this is related to Bug #118404.  I haven't had any JS related
problems.

Comment 2

[Geoff Elliott]

Now, without changing any of the default settings (or moving any bookmarks) the
new profile is as useless as the first one.  It lasted a few hours.

Comment 3

[Andrew Hagen]

This is an important bug report, and a well written one. For various reasons,
it's necessary to be highly specific about what's going on.

Have you been able to narrow it down to one or two possible causes? Is it that
visiting a series of sites will corrupt the profile? If you change your
Preferences, does that have an effect? Which of your profile files are becoming
corrupt?

I really want to confirm this bug, because I know it's a real problem. It will
be solved much faster if we can narrow the problem down.

Comment 4

[Geoff Elliott]

So far I have not been able to narrow the cause down to any one thing, or any
series of things.  I have created a new profile that is working, but I have yet
to add any bookmarks, add my newsgroups, change all of my Preferences, etc.  I
will start doing these things one at a time to see if I can get something to die.

How would I know if one of my profile files is corrupt?  I used the term
"corrupt" loosely in my initial report; my reasoning was that changing to a new
profile fixed the problem (albeit briefly) so one of those files must be the
source.  I really don't know if a file is corrupt, or if something else if
causing Mozilla to choke.

Comment 5

[Andrew Hagen]

When a profile becomes corrupt, the corruption has often been in prefs.js. It's
not that there's a lot of binary junk in the file, but that the values are out
of place, or that character strings are placed where numeric values are supposed
to be.

I'm not sure what would cause a profile to become so corrupt that it screws up
stylesheets.

Comment 6

[Geoff Elliott]

I don't know whether to be happy or irritated.  I've completely config'd my new
profile for use, and have done everything that I might normally do with Mozilla,
and it's running perfectly.  Nothing that I haven't already filed a bug on anyway.  

The older profiles are still, however, hosed.  If you like I could zip those
directories and send them in.  But, honestly, since I can't get Mozilla to screw
up again your time is probably better spent on a reproducible bug.

Comment 7

[Andrew Hagen]

All right, we can resolve it as worksforme if you want. Or do you want to keep
working on it?

Comment 8

[Geoff Elliott]

Once again I am unsure whether to be happy or dismayed: I managed to hose the
latest profile.  I think what did it was using the same profile for Netscape
6.2.  Immediately after I did that the same problems popped up.

Comment 9

[Asa Dotzler [:asa]]

try one at a time renaming the files in your hosed profile and then try starting
 the browser (new versions will be created at startup). when you find the file
that when renamed allows the browser to start compare that file with the clean
version that is created at startup. report back with the difference between the
two files. if you can also confirm your sharing the profile theory that would be
useful too. thanks for your help in testing Mozilla and reporting bugs

Comment 10

[Geoff Elliott]

I can confirm that what hosed the profiles was Netscape 6.2.  The offending file
seemed to be _CACHE_001_.  I was able to reproduce this with 2 old profiles from
Mozilla 0.9.7+ (using 0.9.8).  As soon as I removed _CACHE_001_ the problems
disappeared.

But the problems disappeared for good.  I can no longer get Mozilla 0.9.8 to
choke after loading the same profile in Netscape 6.2.  If I create a new profile
with 0.9.8, use it, load it in NS6.2, then load it again with Moz0.9.8, there
are no problems.  If I create a profile in NS6.2, and go back and forth between
the two programs, still no side-effects.

Here's hoping that with 0.9.8 the problem is inadvertantly fixed.  Might as well
resolve as worksforme.

Comment 11

[Andrew Hagen]

Resolving as worksforme on the basis of the last comment.

I invite you to take a look at bug 107694, which approaches this problem from a
different angle. There is some further related work in bug 123027. 

Thank you very much for all your help. 

Comment 12

[Geoff Elliott]

I managed to do it again.  Once again it was after switching profiles between
Mozilla and Netscape 6.2.  Once again deleting _CACHE_001_ solved the problem.  

I am unable to reproduce this whenever I want, which is aggravating.  It almost
seems random sometimes.  

Some new observations:

1. A shift-reload will force the page to load any associated stylesheets.  This
page will then display properly for any subsequent visits.  I assume this is
because a offending entry in _CACHE_001_ has been overwritten by a
Mozilla-friendly version by the shift-reload.

2. Immediately after noticing the reappearance of the bug I closed the browser
and copied the _CACHE_001_ file.  Deleting it restored normal function.  If I
create and new profile and place this screwed-up _CACHE_001_ file in it's cache
directory, I notice no unusual activity.  I don't know exactly how the cache
works, but I'm guessing that because these pages are loading in the new profile
for the first time it doesn't rely on information within _CACHE_001_, thus grabs
all the files from the server(akin to shift-reload) and does just fine.  Yes/No??

Separating the profile directories as mentioned in bug 107694 would probably be
a good workaround for this.   

Comment 13

[Andrew Hagen]

Sounds like bug 195746. Reopen if you can still reproduce this on a current build.