831226 - Unresponsive when receiving an email with many headers (View > Headers > All). Should sanity check headers

Status: NEW

(MailNews Core :: Backend, defect)

Description

[Vincent (caméléon)]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20100101 Firefox/15.0
Build ID: 20120824154833

Steps to reproduce:

I receive a newsletter from http://cuisine.notrefamille.com/ (attached to this bug report).
For an unknown reason, the mail seems to have been corrupted and thousands of line like 
"X-actif: no
X-actif: yes
X-actif: no"
have been added to its source code.


Actual results:

Thunderbird become unresponsive when trying to open the email


Expected results:

Thunderbird should continue to works normally

Comment 1

[rsx11m]

What does "unresponsive" mean? Does it simply take longer until the message shows up and Thunderbird appears stalled (parsing of that many headers may be slow, do you see something close to 100% CPU activity in task manager?); or, does it hang indefinitely until you terminate the application? Does the same happen after removing the thousands of extra lines, to determine if they indeed cause it?

You said "(attached to this bug report)" but there is no attachment, or is that link hidden somewhere in the forum thread you are referring to?

Comment 2

[Vincent (caméléon)]

Attachment: mail that cause the bug

this is the problematic email that cause the bug

Comment 3

[rsx11m]

Thanks! The message eventually loaded after 10-12 minutes, intermittently updating the UI for the progress bar and header section, but mostly staying in the Windows "(not responding)" stage with full load on one core.

Removing the "X-actif:" headers indeed opens the message instantaneously, but that's not the only contributing factor:

> List-Unsubscribe:
>  http://cuisine.notrefamille.com/v2/mailling/unsuscribe4.asp?id=...

That line break causes the parser to go off track before, thus all headers after that are considered part of the message content and displayed as such.

Consequently, another known bug kicks in (don't have bug numbers right now) with performance issues when trying to render long plain-text attachments or messages.

So, that's likely a duplicate, unless an extreme number of headers should be considered a separate case.

Comment 4

[Vincent (caméléon)]

Many thanks for taking the time to test it yourself. I should admit that I have absolutely no knowledge in this field.
Don't hesitate to close  this report if you think that this is already known issues in Thunderbird.

Comment 5

[rsx11m]

I've done some further testing with the message cleaned up, i.e., joining the "List-Unsubscribe:" header and removing an empty line (#10022) among the "X-actif:" headers. With those changes, the message showed up correctly as HTML and within a few seconds. However, switching from View > Headers > Normal to All stalled the viewer UI again in a "(not responding)" state.

I've terminated the process after 20 minutes of full CPU core use, at which time it occupied more than 1GB RAM. Thus, there still appears to be a performance issue with large amounts of headers independent from plain-text body parsing.

I'll leave this open for other opinions as it appears to be a different issue.

Comment 6

[Wayne Mery (:wsmwk)]

yeah, I'd say this is a duplicate - pick your poison :) - unless you a significant new twist on the issue there's no reason to keep one more bug open.

Comment 7

[Vincent (caméléon)]

so I let you choose which of the 3 bugs listed by rsx11m is the good one to close this report, as I don't feel able to do it myself.

Comment 8

[rsx11m]

Contradicting myself, I think that this is an issue independent of any of the other bugs - those relate to parsing the /content/ if it is a large plain-text part, mostly Core bug 367116 of which MailNews bug 210943 is a special case.

In contrast, the issue described here does not occur when /parsing/ the message but when trying to render the /headers/ for display. This has a different root cause, should happen at a different location in the code, hence a distinct bug.