Closed Bug 554581 Opened 14 years ago Closed 14 years ago

crash on big IMAP account [@ memcpy | msg_parse_Header_addresses] and [@ msg_parse_Header_addresses] (v3.0.x)

Categories

(MailNews Core :: MIME, defect)

Product:
MailNews Core
Component:
MIME
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 564698

People

(Reporter: rcolmegna, Unassigned)

Details

(Keywords: crash, Whiteboard: [needs protocol log])

Crash Data

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 (.NET CLR 3.5.30729)
Build Identifier: LANIKAI - 3.1 beta 1

Hi,
I installed 3.1b1 on a winXP PC (512MB RAM). Using it against an IMAP account which has about 30 folders (but have two folders with 40,000 and 190,000 mails) the client crash.

On the same account TB 2.0 do not crash.   I have noticed that the crash appears when Lanikai pass the 200MB of used memory.

The strange think is that the current TB 2.0 use only 100MB, on the same mailbox.

Reproducible: Always

Steps to Reproduce:
1. open Lanikai
2. crash after 2 mins
3.
Actual Results:  
crash

Expected Results:  
not crash

I have posted crash raport, via Lanikai crash reporter (from "rcolmegna@tiscali.it")
Roberto, does the problem happen with thunderbird started in safe mode?
 https://support.mozillamessaging.com/en-US/kb/Safe+Mode

also, we need your crash report id per http://kb.mozillazine.org/Breakpad#Viewing_crash_reports
Keywords: crash
Roberto, found your crash at bp-de8f069d-a934-487b-87bc-8ee9c2100323 

@ memcpy | msg_parse_Header_addresses signature is 3.1 and 3.2 only
@ msg_parse_Header_addresses  is found for all three branches 

there may be two or more different stacks amongst these crashes, some have different line numbers

Roberto's bp-de8f069d-a934-487b-87bc-8ee9c2100323
0	mozcrt19.dll	memcpy	 memcpy.asm:350
1	thunderbird.exe	msg_parse_Header_addresses	mailnews/mime/src/nsMsgHeaderParser.cpp:640
2	thunderbird.exe	nsMsgHeaderParser::ParseHeaderAddresses	mailnews/mime/src/nsMsgHeaderParser.cpp:196
3	thunderbird.exe	nsParseMailMessageState::FinalizeHeaders	mailnews/local/src/nsParseMailbox.cpp:1445
4	thunderbird.exe	nsParseMailMessageState::ParseFolderLine	mailnews/local/src/nsParseMailbox.cpp:684
5	thunderbird.exe	nsParseMailMessageState::ParseAFolderLine	mailnews/local/src/nsParseMailbox.cpp:666
6	thunderbird.exe	nsImapMailFolder::ParseAdoptedHeaderLine	mailnews/imap/src/nsImapMailFolder.cpp:3011
7	thunderbird.exe	nsImapMailFolder::ParseMsgHdrs	mailnews/imap/src/nsImapMailFolder.cpp:2964 

bp-059b62d5-7eb7-42d1-9075-77cce2100318 3.2a1pre (gjorgjioski)
0	thunderbird.exe	msg_parse_Header_addresses	 mailnews/mime/src/nsMsgHeaderParser.cpp:512
1	thunderbird.exe	nsMsgHeaderParser::ParseHeaderAddresses	mailnews/mime/src/nsMsgHeaderParser.cpp:196
2	thunderbird.exe	nsMsgHeaderParser::ParseHeadersWithArray	mailnews/mime/src/nsMsgHeaderParser.cpp:186
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: crash on big IMAP account → crash on big IMAP account [@ memcpy | msg_parse_Header_addresses] and [@ msg_parse_Header_addresses] (v3.0.x)
Version: unspecified → Trunk
> Roberto, does the problem happen with thunderbird started in safe mode?

yes. See below:

Add-ons: {972ce4c6-7e08-4474-a285-3208198ce6fd}:3.1b1
BuildID: 20100302141414
CrashTime: 1269443075
EMCheckCompatibility: true
Email: rcolmegna@tiscali.it
FramePoisonBase: 00000000f0de0000
FramePoisonSize: 65536
InstallTime: 1269011193
ProductName: Thunderbird
ReleaseChannel: beta
SecondsSinceLastCrash: 28979
StartupTime: 1269442891
Theme: classic/1.0
Throttleable: 1
URL: 
Vendor: 
Version: 3.1b1
I have traced the network traffic between TB and IMAP srv.

Could be that the crash is due to a msg without some headers?

The last command sent from client is something like this:

8 UID fetch 231416 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type)])

the last sent packet, from server, is something like this:

* 87355 FETCH (UID 231416 RFC822.SIZE 3632 FLAGS () BODY[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type)] {317}
From: "Nokioteca Forum" <webmaster@nokioteca.net>
To: d9d9d9d9@XXXXX.it
Subject: Nuova registrazione a Nokioteca Forum ( Nokioteca Forum )
Date: Wed, 18 Feb 2009 15:01:06 +0100
Message-ID: <200902181401.n1IE16a6026412@managed252.serverclienti.com>
X-Priority: 3
Content-Type: text/plain; charset="iso-8859-1"

)

as you could note there isn't some headers.
We parse the headers in batches, so the crash could be caused by any of the previous 20 or so messages whose headers we were downloading.

the tail end of an imap protocol log would be helpful - https://wiki.mozilla.org/MailNews:Logging#Main_Logging_options_within_MailNews
I have tried to enable log on TB.  But the >300MB log file and the concurrent IMAP connections produce a hard to read log.

Again: I note that, as for TB2, the log hasn't timestamps (some log libraries, I suppose) ....  :(
you can add timestamps to the log by adding the timestamp module, per the instructions, e.g., imap:5,timestamp.

As I said before, it's most likely at most the last 100K of the log that are interesting...
Component: General → MIME
Product: Thunderbird → MailNews Core
QA Contact: general → mime
Whiteboard: [needs protocol log]
I have added the timestamp, but the log seem to be not useful (see below).
Isn't impossible that the log isn't flushed to disk due to crash ...
The previous 100K is only the base-64 encode due to an email's attached file.

2010-05-07 14:47:38.890000 UTC - 764[3dbbbc0]: 7dc9800:imap.sfsdfsd.it:S-folder 4/4.2/4.2.1/4.2.1.1:CreateNewLineFromSocket: To: "Utenti di Borse.it:"@web.borse.it;^M
2010-05-07 14:47:38.890000 UTC - 764[3dbbbc0]: 7dc9800:imap.sfsdfsd.it:S-folder 4/4.2/4.2.1/4.2.1.1:CreateNewLineFromSocket: Subject: Rassegna Stampa del 16-02-2009^M
2010-05-07 14:47:38.890000 UTC - 764[3dbbbc0]: 7dc9800:imap.sfsdfsd.it:S-folder 4/4.2/4.2.1/4.2.1.1:CreateNewLineFromSocket: Date: Mon, 16 Feb 2009 09:02:05 +0100^M
2010-05-07 14:47:38.890000 UTC - 764[3dbbbc0]: 7dc9800:imap.sfsdfsd.it:S-folder 4/4.2/4.2.1/4.2.1.1:CreateNewLineFromSocket: Message-ID: <f8bf856349a02064eb93291dac91b71d@mail.borse.it>^M
2010-05-07 14:47:38.890000 UTC - 764[3dbbbc0]: 7dc9800:imap.sfsdfsd.it:S-folder 4/4.2/4.2.1/4.2.1.1:CreateNewLineFromSocket: Content-Type: text/html; charset=iso-8859-1^M
2010-05-07 14:47:38.890000 UTC - 764[3dbbbc0]: 7dc9800:imap.sfsdfsd.it:S-folder 4/4.2/4.2.1/4.2.1.1:CreateNewLineFromSocket: ^M
2010-05-07 14:47:38.890000 UTC - 764[3dbbbc0]: 7dc9800:imap.sfsdfsd.it:S-folder 4/4.2/4.2.1/4.2.1.1:CreateNewLineFromSocket: )^M
2010-05-07 14:47:38.890000 UTC - 764[3dbbbc0]: 7dc9800:imap.sfsdfsd.it:S-folder 4/4.2/4.2.1/4.2.1.1:STREAM:CLOSE: Normal Message End Download Stream
perhaps the fix for bug 564698 fixed this as well - see builds here - http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.2/
it seem fixed. I wrote "seem" because with the previous beta Linkai crash after 10 minutes of CPU-saturation.

Now, after 50min of CPU-saturation, it continue to work.  

The performances are already a problems.
With >200,000 mail/folder Linkai ... need a computational cluster!  ;)

bye
Roberto, thx for the update.
marking dup. We're still tracking related issues in bug 567106
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Crash Signature: [@ memcpy | msg_parse_Header_addresses] [@ msg_parse_Header_addresses]
You need to log in before you can comment on or make changes to this bug.