Open Bug 249195 Opened 21 years ago Updated 2 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: 20 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: