Happened to me, too, after I removed my localstore.rdf. I filed 42516 (which
I'll mark as a dup of this one). Putterman's checkins to
mailnews/base/resources/content fix the problem for me, and also the other
problem I was seeing with the headers in the thread pane.

The problem is reproducible the 2nd time you try to run seamonkey. The first
time you migrate or create a new profile, you can successfully open mail.
I can reproduce this bug on Windows 98 installed on a PIII Dell Precision 210
and on Windows NT 4.0 SP6 installed on a Compaq 6000 deskpro using the
2000-061409-m17 build.
*I migrated my profile and it allowed me to openning mail. I was able to
successfully log into my IMAP mail the first time. The next time I launch
seamonkey and try to open mail, my systems freeze. On NT and 98, my CPU is
peaked at 100% and mail fails to open.
*I created a new profile and was successful in openning mail, entering my mail
info, and logging into mail the first time. The next time I launch seamonkey
and try to open mail, my systems freeze. On NT and 98, my CPU is peaked at
100% and mail fails to open.
I have to end the task.

Just downloaded the bits timestamped 1:31pm since I assume this is the respin.
The problem is still reproducible.
I don't typically migrate or create new profiles, so pmock's steps seem
believable, except that it isn't the "second" time you run mozilla if you're
trying to reuse the same profile.

Phil - release hasn't announced a respin build yet and I don't see anything
later than 2000-06-14-09-m17 (even after a shift+reload of the page).
Peter - can you try again for me if there is a new build? I was never able to
reproduce this problem (even the second time of launching seamonkey) so I can't
comment to Phil's findings.
Thanks

phil is correct, this respin is getting put in the same directory, because it's
two xul file changes, and the automation uses the preexisting buildid to
determine directory.
In any case... phil could this be a corrupt rdf file or some other corrupted
data file?

fyi, I just downloaded the bits from 1:33 and I am still experiencing the problem
I described earlier. I can bring up mail the first time then it freezes the 2nd
time around. I have to kill the task at this point.
/Peter

I just re-pulled and built with putterman's changes on Linux and everything
works just peachy. I think this is just a Windows nmake disaster with the
previous bits. Let's not hold the tree closed for this.

We can reopen the commercial tree if:
(1) Development confirmed that putterman's changes corrects this problem. Since
Akkana had the problem with starting and then confirmed that putterman's changes
fixes it, then I think this step is done. Akkana - to confirm, your problem was
that you couldn't start, right?
(2) Respins with these changes are on their way to QA. We've had two respins so
far and they still show the problem. leaf will work with putterman to figure
out why the changes are making it in.
(3) There are two other bugs which I would consider smoketest blockers -
http://bugzilla.mozilla.org/show_bug.cgi?id=42485 and
http://bugzilla.mozilla.org/show_bug.cgi?id=42488
Putterman says the fixes to xul files also fixes those two bugs (thus the
downgraded severity on those bugs). I'd like to have one other person
verify them besides putterman. I couldn't tell from Don's comments if all
he did was start the product or if he tried the above two bugs. Akkana - if you
can verify the changes on your development build (since we don't have respins),
that would be great.

Ok, one more time. This time, the problem was the commercial build system not
picking up new mozilla files in dist.
mozilla bits work, am respinning commercial bits with the corrected files (no,
really!).

Dan and I tested today's debug builds on all platforms. It works on all of
them. I'm unable to reproduce this crasher. Are we sure this isn't just some
horkage in the build/install process? We know this was broken yesterday...

no idea. seeing as how all these files were changed without informing build
release, who knows what's going on or what's being delivered on win32 right now.
I wouldn't trust today's win32 build as far as I could throw it.

According to gemal in Bug #42605, he sees exactly this same problem. If he
deletes his localstore.rdf, he can open mail without hanging. The symptoms sound
identical to what Phil is seeing.
Phil, can you try deleting your localstore.rdf to test if your mail problem goes
away?
If so, we should make 42605 a dup of this bug.

here's why it may not launch the first time, but it will the second time.
the first time, on a new profile, do you have that crazy 6.0 start page?
(with the big floating "6", etc.)
having that page up causes all sorts of problems and it pings the CPU.
the second time in, you'd have your home page or something.
does that make sense?

I have been told that working on my focal is higher priority than working on
dogfood or smoketest blockers. This bug should probably be re-assigned if you
want it handled quickly, because I'm going to have to work on focal stuff today.

Ok, apparently it goes like this:
dogfood ----> focal ---> smoketest blocker
So I guess the bug is higher priority. Anyway, I can't reproduce this, so I'm
not sure what you want me to do with it. If it's an old tree widget bug, I'm
not inclined to fix it, since the new tree is ready to land (but I'm told the
new tree must land in a carpool, so I'm not allowed to turn it on this late in
the day).

do we have any tree changes in mailnews that were made to help work with the new
tree that are checked in? The only thing I can thing of that mailnews uses
localstore.rdf is to store column widths for the tree widget.
Something is corrupting that information every other time you run. jefft now
sees this on his tip build too.

Hmmmm, maybe this isn't just a Windows-only problem. I'm seeing something
similar to this on my linux mozilla build today. But I can open the mail
window, select folders, etc., but ... after mousing around for about a minute,
my debug build just goes bye-bye. No console message, no core. Just gone.
Truly weird. Does anyone else see this on linux?

that's the same evil stack trace for:
crash when clicking on "add" in sidebar
crash when running mail first time after installing.
that stack trace is valid, but I'm not sure it is related to this bug.
too many bugs going on right now.

I checked in a one-liner that will disable my changes from last night. This
should clear up the crash the Scott is seeing. There is no bug open for
Scott's crash (sent to the hook). I am also not able to reproduce Scott's crash
in my Linux build pulled from immediately after my changes so I'm just checking
it in now to eliminate it as cause of the others.
This does not clear up the "funky stack" crash above. I honestly don't think
that's related to my checkin, despite the scrollbar on the stack.

Hmm everyone is putting comments in the wrong bug report. This smoketest blocker
is not a crash it's a hang caused by a corrupt localstore.rdf
Pollmann, you said we don't hae a bug for the mail crasher. We do. it's actually
assigned to you: Bug #42686. This was the smoketest blocker from this morning
which caused mail to crash. Seth added some bullet proofing to the view manager
to prevent the crash and then it was re-assigned to you.

Could someone who can reliably reproduce this bug attach their "corrupted"
localstore.rdf to the bug?
As a side note, I was noticing some potentially related problems with the file
cache today: the messenger start page's entry had become corrupted and was
taking a very, very long time to load.