Slow/Hang/lock-up on long From lines in header with high cpu

RESOLVED FIXED

Status

MailNews Core
MIME
--
critical
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Jon Watte, Assigned: Karsten Düsterloh)

Tracking

({hang, perf, verified1.8.1.13})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: 2.0.0.9 (20071031)

I received a message with a very long From line. Whenever this message moved into the message list view through scrolling, Mozilla hung/locked up. Removing the inbox index file, and/or rebuilding it did not fix the problem. Removing this particular From: line from the message using a text editor resolved the problem.

Reproducible: Always

Steps to Reproduce:
1. Receive this particular message.
2. Scroll your Inbox so it should include this message.

Actual Results:  
3. Observe hung mail client.

Expected Results:  
3. Message is displayed, with some truncation of From header

I will enclose the message itself in an attachment.
(Reporter)

Comment 1

9 years ago
Created attachment 300706 [details]
email message causing hang

I cut this message out of my Inbox. It was the last message in the Inbox; don't know if that matters to the reproducibility of the bug.
(Assignee)

Comment 2

9 years ago
Whew, 182644 characters in the From: line (RfC 2822 allows for 998), almost all of them illegal, because of the missing charset declaration. 
Anyway, we shouldn't hang on that...

Which version of which program are you using?
You're talking of Mozilla, your User-Agent says Firefox, but product is set to Thunderbird...
(Assignee)

Comment 3

9 years ago
Anyway, happens for SeaMonkey as well, and the problem is, that comi18n.cpp::utf8_nextchar is just grossly slow...
<http://mxr.mozilla.org/seamonkey/source/mailnews/mime/src/comi18n.cpp#170>
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 4

9 years ago
Created attachment 300752 [details] [diff] [review]
optimized UTF-8 recognition

The function utf8_nextchar calls strlen for each of the 180000 characters, which results in a 12s hang even on my machine _per_ usage of the header. On display, it's parsed several times (eg on each repaint), which makes the app very unresponsive...
Assignee: nobody → mnyromyr
Status: NEW → ASSIGNED
Attachment #300752 - Flags: superreview?(neil)
Attachment #300752 - Flags: review?(neil)
(Assignee)

Updated

9 years ago
Status: ASSIGNED → NEW
Component: Mail Window Front End → MailNews: MIME
Keywords: hang, perf
OS: Windows XP → All
Product: Thunderbird → Core
Hardware: PC → All
(Assignee)

Updated

9 years ago
Assignee: mnyromyr → nobody
QA Contact: front-end → mime
(Assignee)

Updated

9 years ago
Assignee: nobody → mnyromyr
(Reporter)

Comment 5

9 years ago
I'm using Thunderbird 2.0.whatever (as pasted in the "product release" field).

That old implementation of utf8_nextchar() was criminally bad! strlen() just isn't a useful function for parsing text.

Comment 6

9 years ago
Comment on attachment 300752 [details] [diff] [review]
optimized UTF-8 recognition

Well, the code looks fine, but I have to admit it looks to me as if return str + 1; would work all the time...
Attachment #300752 - Flags: superreview?(neil)
Attachment #300752 - Flags: superreview+
Attachment #300752 - Flags: review?(neil)
Attachment #300752 - Flags: review+
(Assignee)

Comment 7

9 years ago
Comment on attachment 300752 [details] [diff] [review]
optimized UTF-8 recognition

It's worth having on branch as well, imo - after nine years. ;-)
Attachment #300752 - Flags: approval1.8.0.15?
(Assignee)

Comment 8

9 years ago
Landed on trunk, thus closing. Waiting for branch approval, though.

Jon, you might want to grab tomorrows nightly build and check with a *test* profile.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Comment on attachment 300752 [details] [diff] [review]
optimized UTF-8 recognition

Is this still wanted for 1.8.0.15?  If so, please make sure this gets approval in the 1.8.1.x branch, too.
Attachment #300752 - Flags: approval1.8.1.13?
Duplicate of this bug: 416151
Comment on attachment 300752 [details] [diff] [review]
optimized UTF-8 recognition

approved for 1.8.1.13, a=dveditz for release-drivers
Attachment #300752 - Flags: approval1.8.1.13? → approval1.8.1.13+
(Assignee)

Comment 12

9 years ago
Comment on attachment 300752 [details] [diff] [review]
optimized UTF-8 recognition

Landed on MOZILLA_1_8_BRANCH.
I didn't intend to ask for 1.8.0.x, thanks for correcting me. :)
Attachment #300752 - Flags: approval1.8.0.15?

Updated

9 years ago
Keywords: fixed1.8.0.13

Updated

9 years ago
Keywords: fixed1.8.0.13 → fixed1.8.1.13
Duplicate of this bug: 424349
I verified this in Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13pre) Gecko/2008030903 Thunderbird/2.0.0.13pre using the trash folder from bug 424349. It hung TB 2.0.0.12 and the above 2.0.0.13pre build was able to deal with this.

Marking this as verified for 1.8.1.13.
Keywords: fixed1.8.1.13 → verified1.8.1.13
broaden summary
Summary: Hang/lock-up on long From lines → Slow/Hang/lock-up on long From lines in header with high cpu
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.