Closed
Bug 31411
Opened 25 years ago
Closed 24 years ago
Crash when I Interupt Message Load Too Often
Categories
(MailNews Core :: Backend, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M17
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)
Comment 2•25 years ago
|
||
Phil found a way to weasel out of owning this bug. Reassigning.
Assignee: phil → selmer
I think this will be very easy to run into and it's a crash.
Keywords: beta2
Comment 5•25 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
Assignee | ||
Comment 6•25 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.
Status: NEW → ASSIGNED
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 10•25 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.
Comment 11•25 years ago
|
||
Mail Review recommends this bug as beta2 stopper. Adding nsbeta2 keyword.
Assignee | ||
Comment 13•25 years ago
|
||
pretty hopeless. I can't reproduce this at all. I would recommend not nsbeta2+
myself.
Assignee | ||
Comment 14•24 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•24 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. =(
Assignee | ||
Comment 16•24 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
down.
Assignee | ||
Comment 17•24 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.
Assignee | ||
Comment 18•24 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.
Assignee | ||
Comment 19•24 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.
Assignee | ||
Comment 20•24 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
Assignee | ||
Comment 21•24 years ago
|
||
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 22•24 years ago
|
||
No problems seen using IMAP, NT 4.0 with july13 commercial build.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•