813496 - high memory usage viewing message with thousands of contacts, until OOM, then crash

Status: RESOLVED DUPLICATE of bug 693295

(Thunderbird :: Message Reader UI, defect)

Description

[krszalay]

Attachment: bogus_mail.zip

User Agent: Opera/9.80 (Windows NT 6.1; WOW64) Presto/2.12.388 Version/12.10

Steps to reproduce:

Just start Thunderbird.


Actual results:

If the attached mail is in the INBOX folder on the IMAP server, about 5 seconds after startup, Thunderbird starts to use all CPU and eat all memory in ~40 MB chunks until system crashes.


Expected results:

If the mail is bogus, Thunderbird should not display it, or just display as much as possible, maybe display an alert, but certainly shouldn't crash the whole app on startup.

Comment 1

[Ludovic Hirlimann [:Usul]]

This is on Thunderbird 16.0.2 ?

Does crash for me on trunk.

Comment 2

[krszalay]

Yes, 16.0.2

Comment 3

[Ludovic Hirlimann [:Usul]]

can you try 17 when it goes out today and comment on the bug if it's fixed or not ?

Comment 4

[krszalay]

sure, will do.

Comment 5

[Wayne Mery (:wsmwk)]

Likely caused by 3,875 contacts in the mail header.

WFM - no crash here using trunk. It uses ~80-100MB memory and then settles back down. This is a class of bug that includes bug 487688, bug 693295, bug 619493, bug 460605. The crash might be the result of something else - an addon, or already high memory usage even before the message is opened.

Comment 6

[krszalay]

Installed v17, problem persists even in safe mode with all extensions disabled :(
Baseline memory usage for Thunderbird as reported by Task Manager is 200 MB, and it goes above 1 GB with that one single mail.

Comment 7

[Wayne Mery (:wsmwk)]

confirming for now. But like a duplicate

Comment 9

[WADA:World Anti-bad-Duping Agency]

FYI.
Bug 619493 is already known problem when To:/CC: etc. contains too many mail addresses. See also bug 693295.
Large virtual memory consumption(and large real memory consumption too) is observed in such problem. So, iｆ memory size for an application is lmited by OS setting, "crash of application due to OOM" itself is pretty ordinal phenomenon.

Please clearly isolate problem of "large virtual memory use(and real memory use too)" and problem of "crash due to OOM" when such memory related problem happened. Simple report of "crash due to OOM happened"  is usually useless for problem analysis of memory related problem of software.