Closed Bug 31411 Opened 20 years ago Closed 20 years ago

Crash when I Interupt Message Load Too Often

Categories

(MailNews Core :: Backend, defect, P3, critical)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: sol, Assigned: Bienvenu)

Details

(Keywords: crash, Whiteboard: [nsbeta2+] ETA 6/22 fix ready to check in)

If I interupt email message loading by clicking to another message - repeatedly 
- I crash. Note: I had to switch messages about a dozen times before I could 
bring down Mail, and I am running IMAP.

Build ID - 2000-03-10-13 commercial, on WinNT

Steps to reproduce:

1. Launch Seamonkey

2. Launch Mail (and authenticate if necessary)

Note: I am running IMAP

3. Find some large messages in your Inbox

4. Click on a large message in the thread pane, and before it has completed 
loading, click to another message in the thread pane. Repeat this many times.

Expected: Message displayed in message pane stops loading when you click to 
another message, and newly selected message begins loading (every time).

Actual: Message displayed in message pane generally stops loading when you 
click to another message, but: 

(a) sometimes the message pane gets out of sync with the thread pane - this can 
be remedied by slowing down your clicking

(b) after repeatedly clicking to another message in the thread pane before the 
previous message is loaded - you crash. I estimate it took me between 10 and 12 
messages before I crashed the app.
Talkback incident ID 6644791.
Trigger Reason:  Access violation 
Thread ID: 228

Call Stack:    (Signature = 0x0c08b80a 355968a7) 
     
0x0c08b80a 
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 557]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, 
line 520]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 
1013]
     
USER32.dll + 0x1820
(0x77e71820) 
QA Contact: lchiang → laurel
Severity: normal → critical
Keywords: crash
Phil found a way to weasel out of owning this bug.  Reassigning.
Assignee: phil → selmer
Wouldn't stop beta2 for this.
Target Milestone: --- → M17
I think this will be very easy to run into and it's a crash.
Keywords: beta2
"Note: I had to switch messages about a dozen times before I could bring down
Mail" doesn't sound that easy to me.

Assigning to bienvenu, looks similar to the delete problems.
Assignee: selmer → bienvenu
Lisa, I'd appreciate it if you could come up with an easily reproducible test 
case for this. I tried it for an hour without any luck.
Status: NEW → ASSIGNED
I will do so on Monday.
This is also on my list of things to do, but I didn't quite get to it last week. 
Will be back on Tuesday and try if Lisa doesn't get a chance.
Putting on [beta2-] radar.
Whiteboard: [beta2-]
I can't get it to crash using 2000-04-18-09m16 commercial build on NT 4.0.

After trying for quite awhile, I was easily able to get into the state where the
message pane was mismatched to thread pane selection and throbber was
stopped/Document Done. I could select another message in the thread pane and
most often it would load (correctly), but sometimes either nothing would load
(it would stay on the last displayed contents in message pane) or it would load
a message other than what I selected (it would load a message which I'd selected
previously, but had interrupted then selected another message ... so the worst I
got was continuing mismatched thread to message pane.  I could select another
folder and return and all was hunky dory.

This was all done on a slow machine, 166mhz.
Keywords: nsbeta2
Mail Review recommends this bug as beta2 stopper.  Adding nsbeta2 keyword.
Whiteboard: [beta2-]
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
pretty hopeless. I can't reproduce this at all. I would recommend not nsbeta2+ 
myself.
I can reproduce a few problems in this area if I just cursor down through a 
bunch of small messages. It turns out that we are dropping the imap connection 
all the time if you do this, because the doc loader now interrupts the mock 
channel, which causes us to think we've been stopped, even if we should just be 
pseudo-interrupted (which means we just wait for the current chunk of the 
current message to finish loading and then load the next message. For a small 
message, this just means wait for the current message to finish loading.) I'm 
trying to fix this by paying attention to the m_pseudoInterrupted flag in 
DeathSignalReceived (ignoring the mock channel status if we've been pseudo 
interrupted). This makes things better, but I'm still working on it. I also 
found that we end up with a lot of idle connections that are not in the selected 
state but have the inbox as their selected mailboxname - this confuses the 
connection cache, so I changed GetSelectedMailboxName to make sure the 
connection is actually in the selected state.
Whiteboard: [nsbeta2+] → [nsbeta2+] ETA 6/22
Oh dear! That's not good. I could have sworn I added code to play nicely using
the psuedo interrupted flag in conjunction with incoming cancel requests on the
mock channel...I guess I didn't. my bad. =(
OK, I have a basic fix for this, involving the stuff mentioned above, and the 
crucial change of NOT running queued urls that have already had their mock 
channel cancelled - they've basically been pseudo interrupted without ever 
getting a chance to run, so loadqueuedurl just removes them and looks for the 
next url to run. This works so that we never kill connnections when cursoring 
through a bunch of messages. I do have a strange problem where m_channelListener 
is null in nsImapProtocol::BeginMessageDownLoad now, that I'm trying to track 
down.
OK, I've figured out the m_channelListener problem. It is an interaction with 
the memory cache. The pseudo interrupted message loads that never got a chance 
to run still have memory cache entries because nsImapMockChannel::AsyncRead is 
called before the imap url is ever run, and creates a cache entry. Later, 
when we try to load the message for real, the storage stream associated with the 
memory cache entries think there's a write in progress (mWriteInProgress is 
TRUE) so it fails to create an output stream. This means the call to 
InterceptAsyncRead fails to create a channel listener. So, somehow, I need to 
either remove the cache entry when we decide not to run the url (if it's 0 
length, I guess) or I need to somehow convince the cache entry that there's not 
a write in progress, either when I decide not to run the url, or when I try to 
run it again.
well, the cache code STILL doesn't allow you to remove entries. That's very 
unfortunate. I'm probably screwed unless I can find some way to trick the cache 
entry into thinking it's not being written to.
my mistake - apparently, you tell the cache entry to delete itself, instead of 
telling the cache manager to delete the entry.  That's just a guess, but it's 
worth a try. It seems like perhaps the correct way of handling this is to abort 
the mock channel in such a way that makes the cache do the right thing and 
realize the cache entry is bogus. The mock channel is already getting cancelled 
- I'm not sure what else should happen.
note that all of the above discussion is not for the crash - I've not been able 
to reproduce the crash.
Whiteboard: [nsbeta2+] ETA 6/22 → [nsbeta2+] ETA 6/22 fix ready to check in
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
No problems seen using IMAP, NT 4.0 with july13 commercial build.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.