110892 - Message text not displayed; attempted reread crashes Mozilla [@ nsStorageTransport::AsyncRead]

Status: VERIFIED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Bruce Feist]

Sometimes (5% of the time as a guess) when I highlight a message header the text
doesn't display and the header stays boldface as though the message is unread. 
If I proceed to another message, it's read normally; if I go back to the one
that didn't display, Mozilla crashes.  The feedback agent has captured
information on this, but I thought it best to do an explicit bug report, since I
didn't see anything like this when I searched.

There's no obvious pattern to the messages that I can see.  When I restart, I
don't have any trouble reading them.

This is typically how I exit Mozilla these days <g>.

Comment 1

[Scott MacGregor]

Here's the stack trace from your talkback reports. Looks like we are crashing in
the memory cache. Your also using a build from the 11th. Any chance you can use
a more recent nightly to see if the problem is still there? What are your memory
cache settings at?

nsStorageTransport::AsyncRead
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStorageTransport.cpp, line 383]
nsCacheEntryDescriptor::nsTransportWrapper::AsyncRead
[d:\builds\seamonkey\mozilla\netwerk\cache\src\nsCacheEntryDescriptor.cpp, line 561]
nsImapMockChannel::ReadFromMemCache
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 7074]
nsImapMockChannel::OnCacheEntryAvailable
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 7018]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 154]

Comment 2

[Bruce Feist]

Memory is set to 4096KB; cache is set to 50000KB.  "Compare the page in cache to
the page on the network" is set to Automatic.  I'll download and install a
nightly build, and update if and when I crash again.

Comment 3

[Bruce Feist]

Yep, it still happens, even with a current nightly build.  I haven't figured out
how to extract an incident ID from TalkBack, or I'd reference it; it happened a
few minutes ago on my [e-mail] account (the same that I'm using now).

Comment 4

[Bruce Feist]

I'd been running TalkBack from the wrong install of Mozilla, which is why I
didn't see any incidents (or incident IDs).  Now that I've run the right one, I
see that the incident ID of my most recent crash is TB38275524X.  Duh.

Comment 5

[K Chayka]

win32 build 2001112408, win98se

I've been experiencing something similar on recent builds, except mozilla
doesn't crash - it just doesn't display the message.  This is most noticable
while reading newsgroups (3-pane view).

1. Read a message that was previously unread (in this session).  The message
body displays.
2. Read another unread message.  The message body displays.
3. Select the first message again.  The message body does not display.
4. Read another unread message.  The message body displays.
5. Select the first message again.  The message body now displays.

So, I can't re-read a post until after a non-cached message is displayed.  It
doesn't seem to make any difference what cache setting I use, but it happens
less often with "Once per session" than with "Every time" (my preference) or
"Automatic".  Memory cache currently set to 8192kb, Disk cache 50000kb.

Comment 6

[Bruce Feist]

I don't think that K Chayka's problem is related to this one.  The problem I
reported occurs on mail -- I don't think I've seen it on newsgroups.  And, once
the message text doesn't display, attempts to reread consistently cause a crash.
 Also, once the text displays the first time, it doesn't vanish when I reread
later on.

Comment 7

[Scott MacGregor]

talback isn't showing this stack trace anymore. I saw it once as I mentioned
before but that was back in the middle of November. 

Comment 8

[Scott MacGregor]

Marking this as fixed since it doesn't appear to be showing up anymore. I also
looked at reports filed by Bruce and he hasn't posted this stack trace in a long
time. Although it looks like he's now crashing in
nsXULPrototypeCache::PutXBLDocumentInfo back on the 3rd of December. 

Comment 9

[esther]

verified