Open Bug 249195 Opened 21 years ago Updated 3 years ago

unable to see message due to Exception in mailWindowOverlay [HandleMDNResponse]

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Platform:
x86
Windows XP
Type:
defect

Tracking

(Not tracked)

Status:
REOPENED

People

(Reporter: bugzilla, Unassigned)

References

Details

(Keywords: fixed-aviary1.0, fixed1.7.5)

Attachments

(3 files, 3 obsolete files)

proposed fix
3.98 KB, patch
mscott
: superreview+
mkaply
: approval1.7.5+
Details | Diff | Splinter Review
proposed fix
1.98 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
fix for another cause of this
811 bytes, patch
mscott
: superreview+
Details | Diff | Splinter Review
when I click on a message I keep getting: Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgMailNewsUrl.mimeHeaders]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/mailWindowOverlay.js :: HandleMDNResponse :: line 2151" data: no] Source File: chrome://messenger/content/mailWindowOverlay.js Line: 2151 build 20040628
I've only seen this on IMAP and other too!
Assignee: sspitzer → bienvenu
Component: Mail Window Front End → Networking: IMAP
QA Contact: grylchan
*** Bug 226295 has been marked as a duplicate of this bug. ***
*** Bug 225512 has been marked as a duplicate of this bug. ***
*** Bug 231521 has been marked as a duplicate of this bug. ***
*** Bug 198372 has been marked as a duplicate of this bug. ***
David: I'm getting this error every day and I have to restart Mozilla to view the message. I'm not seeing anything weird in the IMAP log
Me too. Well, moving the message to another folder works too (cumbersome but avoids a restart).
(In reply to comment #1) > I've only seen this on IMAP and other too! (In reply to comment #4) > *** Bug 231521 has been marked as a duplicate of this bug. *** "My" bug report was based on POPv3(= "local") folders: I was not using IMAPv4 at all.
Serge, do you have a message that reliably causes this problem?
(In reply to comment #9) > Serge, do you have a message that reliably causes this problem? No :-( But I'm setting my BugZilla folder back to Threaded mode: I'll post a comment if(/when) it happens again...
David: I'm pretty sure this isn't limited to a specific message. I'm getting this once a day. Then I shut down Mozilla and start it again and I can see the message.
I wonder if these assertions in a debug build are related (I couldn't verify that yet): ###!!! ASSERTION: OnDataAvailable implementation consumed no data: 'Error', file c:/mozilla_source/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 457 Break: at file c:/mozilla_source/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 457 ###!!! ASSERTION: unknown error, but don't alert user.: 'errorID != UNKNOWN_ERRO R', file c:/mozilla_source/mozilla/mailnews/base/util/nsMsgProtocol.cpp, line 40 0 Break: at file c:/mozilla_source/mozilla/mailnews/base/util/nsMsgProtocol.cpp, l ine 400 They seem to always appear together.
Attached patch workaround fix... (obsolete) — — Splinter Review
Ere, can you try this patch? It checks, in a roundabout way (because I couldn't find a direct way), if a mem cache entry is 0 bytes long, and if so, returns an error. That error should cause us to fall back to fetching the message from the server. It still doesn't explain how a 0 byte mem cache entry was created...
I can try the patch. But I think I know how to reproduce this. Take one screenful of old messages in a folder. Very quickly click through them with the mouse to load them from the server. Then check the messages one by one. I can see at least one empty message almost every time. I ran for a while without junk mail controls and didn't see the problem. I think junk mail controls trigger the same problem by downloading the new messages quickly.
Comment on attachment 153841 [details] [diff] [review] workaround fix... The patch doesn't help. I still get 0 size entries that fail to show.
Ere, can you try setting a breakpoint on the code that returns an error with a 0 byte cache entry? I'm wondering if you're hitting that code or not... in->Available(&bytesAvailable); if (!bytesAvailable) return NS_ERROR_FAILURE; this bug is relatively new, isn't it? I wonder if something changed in the memory cache...
I can't reproduce this exactly, but I can definitely reproduce a case where a partial message ends up in the memory cache. I thought we had some logic to doom cache entries when they were only partially in the mem cache but it seems to have broken. I wonder if the mock channel isn't getting cancelled anymore in the case of pseudo-interruption...
Attached patch Partial workaround (obsolete) — — Splinter Review
The call to in->Available fails with result code 0x80070057 leaving bytesAvailable uninitialized. This is my modified version of the patch. It works so far as to loading the message succesfully, but it doesn't correct the cache entry, which means it's loaded from the server every time.
Attachment #153841 - Attachment is obsolete: true
Attached patch Workaround patch (obsolete) — — Splinter Review
Added a call to entry->Doom() if the entry is invalid so it can be properly cached when loading again.
Attachment #154010 - Attachment is obsolete: true
great, thx. I'll probably propagate the rv from the Available failure. I'm still trying to figure out how these empty cache entries get created. I'm worried that partial cache entries are also getting created, which we can't detect as easily. I verified that we are dooming cache entries in some situations but we're still ending up with invalid cache entries.
For me, this corresponds to the following assertion at line 1305 (which is debug_bienvenu) NS_ASSERTION(m_imapMiscellaneousSink, "null sink"); From the imap log, we're retrieving the whole message, and marking the cache entry valid. So my guess is that we're not writing any of the data into the cache. I believe what's happening is that we're calling ReleaseUrlState on an imap protocol object that we've already set up to run the next url, and that's clearing the channel listener, so the data isn't get written into the cache.
David, you could try backing out my mock channel changes pretty easily to see if your reproducible test case goes away. That was for Bug #244325. Just uncomment the m_url = nsnull; line. http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/mailnews/imap/src&command=DIFF_FRAMESET&file=nsImapProtocol.cpp&rev1=1.566&rev2=1.567&root=/cvsroot
thx, yeah, I don't think that's the issue - I suspect it has to do with a change I made to fix a race condition :-( or it's just the race condition in general when we re-use a protocol object to run a url.
Status: NEW → ASSIGNED
the imap thread is busy in ReleaseUrlState, which is proxying this call: m_imapMailFolderSink->ReleaseObject(); meantime, on the ui thread, nsImapMockChannel::OnCacheEntryAvailable() is called and we fall into ReadFromImapConnection(), I think because we're trying to run a url to download the msg and write it to the mem cache...ReadFromImapConnection calls GetImapConnectionAndLoadUrl, which calls LoadImapUrl, which calls SetupWithUrl, which initializes the channel listener to write to the mem cache entry. This all finishes, the ui thread can process the m_imapMailFolderSink->ReleaseObject() call, and fall through to the code that clears the channel listener. So the fix might be to clear the channel listener earlier in ReleaseUrlState. A monitor might be dangerous since we might end up deadlocked. I've also seen a case where we make multiple connections to the inbox while reproducing this bug. And I need to fix bug 246439 which is another race condition. I'll try to fix all three of these.
Attached patch proposed fix — — Splinter Review
clear the listeners before we mark the connection free - it will avoid clearing the sinks on a new url.
Attachment #154011 - Attachment is obsolete: true
Attachment #154050 - Flags: superreview?(mscott)
Comment on attachment 154050 [details] [diff] [review] proposed fix is checking the bytes available from the memory cache stream still necessary now that you are more agressive about clearing out listener state?
Attachment #154050 - Flags: superreview?(mscott) → superreview+
it may not be necessary, but I think it's a good thing to do...an empty cache entry has to be wrong.
fixed on trunk - Ere, let me know if you see any problems with this fix...
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Works great :) There seems to be some extra code in OnCacheEntryAvailable: + nsCOMPtr <nsIImapUrl> imapUrl = do_QueryInterface(m_url); + These should be removed, right?
Ere, glad it's working. I'll remove those extra nsIImapUrl's - I was adding logging about the dooming of cache entries to help debug this, and when I removed the logging, I forgot to remove those lines.
Keywords: fixed-aviary1.0
*** Bug 210716 has been marked as a duplicate of this bug. ***
Comment on attachment 154050 [details] [diff] [review] proposed fix I think this should be in 1.7.3 as well - I believe it fixes several different problems, like bug 247914
Attachment #154050 - Flags: approval1.7.3?
Comment on attachment 154050 [details] [diff] [review] proposed fix a=mkaply for 1.7.3
Attachment #154050 - Flags: approval1.7.3? → approval1.7.3+
*** Bug 243548 has been marked as a duplicate of this bug. ***
*** Bug 247914 has been marked as a duplicate of this bug. ***
Keywords: fixed1.7
David: You meant fixed1.7.3 instead of fixed1.7, didn't you !?
Keywords: fixed1.7 → fixed1.7.3
thx, Serge, I didn't know we had a keyword for that.
I think this is related so reopening, if not say and I'll open a new one. Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgMailNewsUrl.mimeHeaders]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/mailWindowOverlay.js :: HandleMDNResponse :: line 2171" data: no] This is using BuildID 2004081008 on WinXP SP1
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ian, how reproducible is this? If you shut down and click on the same message, does it happen again? This is an imap message?
This happens on an IMAP mail account in 3 pane view when deleting a message from the inbox (as that is about the only place I delete email from). I highlight the message (message A) I want to delete and it displays in the 3rd pane. I click on the delete button. The message gets deleted and the next message down (message B) is highlighted but the 3rd pane still shows the header information from the deleted message (message A). If you click on a different message, it displays that message correctly in the 3rd pane. If you then go back to message B, the header from the deleted message (message A) is once again displayed in the 3rd pane. Examing the JS console gives the error message in comment #38 for each time you click on message B. Exiting and going back into mozilla does fix the issue. It does not happen everytime I delete a message, though it does happen a couple of times a week when using mozilla constantly. I seem to think that the message B is usually an email with attachments but I'm not sure if that has any significance.
do you use the imap delete model, or the delete to trash delete model? Is your Inbox configured for offline use? I'm surprised you're seeing this, since Ere and I pretty much nailed the empty message in the memory cache issue, I thought.
Using the move to trash folder delete model and inbox is not configured for offline use.
Using BuildID 2004082007 on WinXP SP1 Steps to reproduce: 1. Have an IMAP mail server and account set with move to trash delete model 2. Have an email message in the inbox with an attachment 3 [details] [diff] [review]. Restart mozilla and log into IMAP server 3. Select that email with mouse and then click on delete icon 4. With mouse select edit and undo delete message 5. With mouse select the undeleted message Expected results 1. Displays that message that has been undeleted Actual 1. Displays the header of previous email at top of message window with blank body. 2. Generates following message in JS console: Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgMailNewsUrl.mimeHeaders]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/mailWindowOverlay.js :: HandleMDNResponse :: line 2159" data: no] Source File: chrome://messenger/content/mailWindowOverlay.js Line: 2159 This only seems to happen on emails you have not already deleted and undeleted in the current instance of mozilla. So if you delete, undelete a message once and get the error message and then try it again on the same message without restarting mozilla you do not get the bug.
running Moz 1.8a3 (20040817) I get the Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgMailNewsUrl.mimeHeaders]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/mailWindowOverlay.js :: HandleMDNResponse :: line 2159" data: no] Source File: chrome://messenger/content/mailWindowOverlay.js Line: 2159 error: It is fairly, but not 100% reproducible. Steps:- STart off with a mailbox with lots of unread messages. set to download messages to local cache for offline use. At least one of the early messages is large, so will take time to download over a releatively slow (ISDN or broadband) connection. start mail; start downloading the files Whilst mozilla is downloading the large message(s), click on a (small) message whose header is downloaded but whose body is not yet downloaded. Of course, you don't get anything. Note that after a while, all network activity ceases, but the messages starting at, and including, the (big) message it was downlaoding, have not been downloaded. click get messages - and wait - mozilla downloads all the messages - except the big message You can't get at the big message - it shows empty. To get to it you have to delete it, and then "undo" - and then the message will download (so this is the workaround) The suspicion is that somehow when the download was interrupted, the cached copy is in a damaged state. Mozilla is set to delete to trash directory, but not sure if thats relevant)
Ian, are you configured for offline use with your inbox? I can't recreate the bug with your steps. Jonathan, yes, that's a somewhat known problem, though I've had a hard time reproducing it.
David - Is there anything I can do to help reproduce it? Snapshots / instrumented versions? It happens fairly regularly with me...
I'm not configured for offline use with inbox as far as I am aware. It did take me a while to find my reproducable case and it may be connected with the IMAP server (Netscape 4.15 Messaging Server) but I have never seen it happen using Netscape 4.80 client. As Jonathan says, if there is any logging or extra debugging that I can do from the nightly builds or my own cygwin/mingw builds then let me know.
yes, thx, in both cases, an imap protocol log would be helpful: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
Okay, I've generated the file, is there any editting that needs to be done prior to uploading? Phone numbers, email addresses, etc? Is it best to upload it here?
Ian, e-mail it to me. You can probably edit out the start of the log up to the point where you first select the message before deleting it. If you don't want to grovel through the whole log to edit it, just send it to me.
*** Bug 201467 has been marked as a duplicate of this bug. ***
Attached patch proposed fix — — Splinter Review
this should fix the problem Jonathan describes - what was happening (to me, at least) was that if you click on a message that happens to be in the disk or memory cache while the offline download was going on, we were stopping the saving of the messages to disk in the offline process. So if we were in the process of downloading a large message, we'd end up with just part of the message. Also, we wouldn't save any of the subsequent messages.
Comment on attachment 158902 [details] [diff] [review] proposed fix this patch also seeks to the end of the offline store before writing a chunk of data, just to be safe.
Attachment #158902 - Flags: superreview?(mscott)
Attachment #158902 - Flags: superreview?(mscott) → superreview+
most recent patch checked into trunk and branch. I haven't received Ian's log yet...
David, I did email it through to you from my work address about 10 minutes after you asked me to. I've just forwarded it again.
Ian, are you e-mailing it to bienvenu@nventure.com ? If it's too big (over 8 MB or so) it'll bounce. If so, you could mail it to david.bienvenu at gmail.com
It's only 191K but that address might not like multiple plain text attachments so I've sent it to your other address.
Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgMailNewsUrl.mimeHeaders]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/mailWindowOverlay.js :: HandleMDNResponse :: line 2160" data: no] Source File: chrome://messenger/content/mailWindowOverlay.js Line: 2160 With the latest patch I still get the above error message following my steps. Hopefully David has got my log file from before now.
Ian, yes, that last fix only had to do with offline, and your problem doesn't appear to have to do with offline. Your log looks OK - we refetch the headers for the undeleted message, and then we fetch the body parts we want to display. Hmm, but we're not refetching the headers for message display, nor do we generate the message headers from the shell cache. That's my guess as to your problem - I'm not sure where deleting and undoing the delete comes into it, however. It would seem like clicking away from the message and clicking back should have the same problem...Could you send me the message in question (edit message as new and change the to: field to me)? Then I can try it with some of my imap servers...
Okay typical message sent to both your email addresses - title is "Netware / Citrix training"
Ian, thx, I can reproduce the blank message problem with the msg you sent (though I don't see the js exception). And I see that clicking away and clicking back does fix the problem. It's still a mystery why your mail doesn't get through to my nventure account, however...it's not in the spam folder...
if you are reading a large message in a folder configured for offline, and before we've finished loading the message, you click on another message, that can corrupt the offline store, and produce this problem. This patch makes sure we stop echoing lines to the offline sink if we've been pesudo-interrupted.
David: I wonder if any of these issues could apply to downloading and/while reading newsgroups too ? I feel like I could be seeing similar behaviours, but I did not try to make testcase(s) yet.
none of the fixes apply to news, but the problem fixed by https://bugzilla.mozilla.org/attachment.cgi?id=158902&action=view could also be a problem in news (I'm not sure). That would be the situation where you're reading news message while a download for offline use of the same newsgroup is going on.
(In reply to comment #64) > none of the fixes apply to news, but the problem fixed by > https://bugzilla.mozilla.org/attachment.cgi?id=158902&action=view could also be > a problem in news (I'm not sure). That would be the situation where you're > reading news message while a download for offline use of the same newsgroup is > going on. That's exactly what I meant: different files to fix (in an other bug to open !?); case: start downloading then open 1+ newly downloaded messages while more are still coming in ... from then on, the next downloaded messages displays as "white/empty", if I remember well. Can you have a look at this directly, or should I test it again to confirm and post reproducible steps (hopefully) in a new bug ?
yes, please, a new bug, assigned to me, with steps to reproduce, for offline news.
Comment on attachment 161171 [details] [diff] [review] fix for another cause of this this fixes the case where the user clicks between messages in a folder configured for offline use, and pseudo-interrupts a message load.
Attachment #161171 - Flags: superreview?(mscott)
Attachment #161171 - Flags: superreview?(mscott) → superreview+
last fix checked in. I'm leaving this open for Ian's bug, though I might spin off a separate bug for that specific problem.
(In reply to comment #66) > yes, please, a new bug, assigned to me, with steps to reproduce, for offline news. I filed bug 263744 for similar NNTP issues.
Will the fix from this (Comment #52) also get into Thunderbird, or do I have to do something to achieve this?
Product: MailNews → Core
I'm still getting this message in BuildID 2005013106 on WinXP SP2 :-( Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgMailNewsUrl.mimeHeaders]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/mailWindowOverlay.js :: HandleMDNResponse :: line 2222" data: no] Source File: chrome://messenger/content/mailWindowOverlay.js Line: 2222
I'm seeing this again too on Mozilla 1.7.8 for one message. Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgMailNewsUrl.mimeHeaders]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/mailWindowOverlay.js :: HandleMDNResponse :: line 2112" data: no] Source File: chrome://messenger/content/mailWindowOverlay.js Line: 2112 I don't have a dev environment on this machine, but will try to reproduce and see if I can find the reason.
Bah, couldn't reproduce in the latest nightly :(
Product: Core → MailNews Core
QA Contact: grylchan → networking.imap
Assignee: dbienvenu → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: