Crash when I Interupt Message Load Too Often



19 years ago
11 years ago


(Reporter: sol, Assigned: Bienvenu)



Windows NT

Firefox Tracking Flags

(Not tracked)


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



19 years ago
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.

Comment 1

19 years ago
Talkback incident ID 6644791.
Trigger Reason:  Access violation 
Thread ID: 228

Call Stack:    (Signature = 0x0c08b80a 355968a7) 
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 
USER32.dll + 0x1820


19 years ago
QA Contact: lchiang → laurel


19 years ago
Severity: normal → critical
Keywords: crash

Comment 2

19 years ago
Phil found a way to weasel out of owning this bug.  Reassigning.
Assignee: phil → selmer

Comment 3

19 years ago
Wouldn't stop beta2 for this.
Target Milestone: --- → M17

Comment 4

19 years ago
I think this will be very easy to run into and it's a crash.
Keywords: beta2

Comment 5

19 years ago
"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

Comment 6

19 years ago
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.

Comment 7

19 years ago
I will do so on Monday.

Comment 8

19 years ago
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.

Comment 9

19 years ago
Putting on [beta2-] radar.
Whiteboard: [beta2-]

Comment 10

19 years ago
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.


19 years ago
Keywords: nsbeta2

Comment 11

19 years ago
Mail Review recommends this bug as beta2 stopper.  Adding nsbeta2 keyword.


19 years ago
Whiteboard: [beta2-]

Comment 12

19 years ago
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]

Comment 13

19 years ago
pretty hopeless. I can't reproduce this at all. I would recommend not nsbeta2+ 

Comment 14

19 years ago
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

Comment 15

19 years ago
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. =(

Comment 16

19 years ago
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 

Comment 17

19 years ago
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.

Comment 18

19 years ago
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.

Comment 19

19 years ago
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.

Comment 20

19 years ago
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

Comment 21

19 years ago
fix checked in.
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 22

19 years ago
No problems seen using IMAP, NT 4.0 with july13 commercial build.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.