138213 - mozilla stalls fetching content of particular mails, possibly due to 8bit data

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: IMAP, defect)

Description

[Blu3]

Moz mail hangs while trying to fetch the content of a particular email [email
and IMAP log located at URL].  I suspect it may be due to the 8bit data in the
Subject or From headers.  Kryptolus loaded the example email in a debug build
and will post some stack traces.  I'm using build 2002 0413 07 on Linux.  IMAP
server is UW and SSL is enabled.

Once that particular email is attempted, moz mail is useless for that mailbox
and everything must be restarted.  No crash, just stall. Note, only that
particular mailbox is affected.  Other mailboxes can be browsed and operated on
normally.

Comment 1

[Vadim Berezniker]

I'll hold off on the stack a bit.
The email consists of a *lot* of nested tables.
The problem goes away if you remove the charset from meta.

Further email will follow shortly.
Trying to make a testcase.

Comment 2

[Vadim Berezniker]

41 seconds to render on 1.5ghz machine ...
I'll hold off confirming until I create a minimal test case

Comment 3

[Vadim Berezniker]

8 nested tables with a form inside the deepest level
removing 'marginheight' and 'marginwidth' from the root table causes the message
to be rendered instantly

will attach the 'somewhat' simplified message (it's still rather large)

Comment 4

[Blu3]

Just to clarify, the initial problem with this email is during the IMAP
fetch procedure on startup.  There are 761 emails in my INBOX, this particular
one is #740.  Moz starts fetching new emails, gets up to #740, and stalls.

Moz isn't trying to render a message body just yet.

Comment 5

[Vadim Berezniker]

Attachment: evil mail message

Comment 6

[Scott MacGregor]

can you attach an imap log?

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Comment 7

[Blu3]

IMAP log is at http://blue-labs.org/mozbugs/imap.stall.log.138213

-d

Comment 8

[Scott MacGregor]

Looking at the log it does indeed look like an 8 bit character parsing issue o
our end. cavin loves these 8 bit bugs. re-assigning.

Comment 9

[Blu3]

Would someone -please- do something about this.  Even a hack that displays raw
data would be fine.  Totally stalling access to the mailbox is unacceptable.

Comment 10

[Blu3]

Attachment: 8bit in headers, ex #1

Comment 11

[Blu3]

Attachment: 8bit in headers, ex #2

Comment 12

[Blu3]

Viewing the offending emails in mozilla works fine, loading them in the mailbox
breaks messenger.

Comment 13

[Cavin Song]

I could not reproduce the problem using message from
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=82669. I sent the
message to an imap account and I saw garbage chars in both the From: and
Subject: headers but the body text showed the right Korean chars. I copied the
message to a local folder and it worked fine as well.

Comment 14

[Blu3]

Attachment: yet another borken mail

That one works fine.  Odd, I must have attached the wrong one.	I'm attaching
another email that it does stall on.  Simply append it to $mailbox.

-d

Comment 15

[Cavin Song]

I still could not reproduce the problem using message from
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=82808.

I compared the my log against the one from comment #6 and the downloaded headers 
are all the same. The difference is that the command used to download the header 
in the log from comment #6 is:

  15 UID fetch 2728:2750 (UID RFC822.SIZE BODY.PEEK[])

and the server response is:

  * 740 FETCH (UID 2728 RFC822.SIZE 24273 BODY[] {24273}

whereas mine is:

  7 UID fetch 1:2 (UID RFC822.SIZE BODY.PEEK[HEADER] FLAGS)

and the server response is:

  * 2 FETCH (FLAGS (\Seen) UID 2 RFC822.SIZE 25045 BODY[HEADER] {1195}

Note that mine does not try to load the message body yet (ie, it uses 
BODY.PEEK[HEADER] instead of BODY.PEEK[]). I'm running a build from this week so 
I think some fixes might have been made to fix the fetch command for similar 
problems.

David, are you still running the build from 04/13/02? Can you try the latest 
build to see if the behavior changes. Can you also attach an IMAP log if it 
still does not work?  Thanks.

Comment 16

[Blu3]

Ok, latest build tested, 5/11 08.  Still have problems.  I put the original
email I'm using (http://blue-labs.org/mozbugs/mail.stall.138213) in a folder,
tried loading it, no go.  I've updated my mozbugs page
(http://blue-labs.org/mozbugs/) and here is the URL to the IMAP
log.http://blue-labs.org/mozbugs/mail.stall.log2.138213

I've added some comments inline w/ the logfile indicating where I was doing
things.  Here's the summary of the unmodified log file:

startup, 463 lines
copy eml file
load bluelist folder
now have 499 lines
clicked on broken email
now have 520 lines
clicked on INBOX again
now have 565 lines

Comment 17

[Blu3]

i believe the rewrite that dealt with embedded NULLs also fixed this.  this bug is WFM now.