User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.13) Gecko/20080327 Camino/1.6b4 (like Firefox/2.0.0.13) Build Identifier: version 2.0.0.12 (20080213) crash report will be posted later. it crashed every time while retrieving messages now, so it may be caused by a certain message retrieved. Reproducible: Always Steps to Reproduce: 1. 2. 3.

the crash report

additional information: my inbox file of local folders is now 2.01GB (2155149858 bytes), maybe this is the problem?

I tried to move some mails out of the local inbox and now it works fine without crash, so the problem should be caused by the 2.01GB file size

May be, may be not. I'm stunned that users value their mail account inbox as an archive. Or, is there a high traffic, throughput, of incoming mail that is moved elsewhere for storing and archiving, while the Inbox is never cleaned up, i.e. is never compacted to remove the hidden messages marked as deleted, in order to save space and processor cycles.

Well, the local inbox stores my work mails. With 2 filters to automatically filter some mails to another mailbox and checked the "Compact folders when it will save over 1024 KB", I do have that many mails.

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/xpcom/obsolete/nsIFileStream.cpp&rev=1.6&mark=451#397 personally, i value my mailbox as an archive. but years ago (2004?) my imap server fell over and in 2005 or so, I switched to gmail, where I keep my bugmail archive. Mail is very valuable. please don't comment in crash bugs about what data users choose to value, it isn't productive.

(In reply to comment #6) > http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/xpcom/obsolete/nsIFileStream.cpp&rev=1.6&mark=451#397 > > personally, i value my mailbox as an archive. but years ago (2004?) my imap > server fell over and in 2005 or so, I switched to gmail, where I keep my > bugmail archive. > > Mail is very valuable. please don't comment in crash bugs about what data users > choose to value, it isn't productive. > Of course, you are right. I was thinking of POP mail, rather.

So this bug is on the issue of a large 2Gb+ inbox size?

(In reply to comment #8) > So this bug is on the issue of a large 2Gb+ inbox size? > should be, as after I reduced the inbox size, it didn't reproduce again

<maskas> i was wondering if someone could help me, my thunderbird client seems to be crashing everytime trys to filter an email <maskas> sp3000: incident id is TB46234552G <maskas> and reported it again with id TB46242635M <maskas> well inbox is around 2 gigs <maskas> sp3000: making the inbox smaller seems to have solved the problem Thunderbird2 2008042104 Windows NT 5.1 build 2600 msvcrt.dll + 0x36fa3 (0x77c46fa3) FileImpl::Write [mozilla/xpcom/obsolete/nsIFileStream.cpp, line 453] nsOutputStream::write [mozilla/xpcom/obsolete/nsFileStream.cpp, line 131] nsParseNewMailState::AppendMsgFromFile [mozilla/mailnews/local/src/nsParseMailbox.cpp, line 2199]

confirming Here's another at line 453 TB45698667 Stack Signature msvcrt.dll + 0xa51d (0x76e3a51d) 0d0d131b Product ID Thunderbird2 Build ID 2008042104 Trigger Time 2008-05-29 09:36:49.0 Platform Win32 Operating System Windows NT 6.0 build 6000 Module msvcrt.dll + (0000a51d) URL visited User Comments My Thunderbird is no longer working. I have been forced to switch to Outlook. I only opened to get old emails. It crashes upon opening. Since Last Crash 727 sec Total Uptime 522559 sec Trigger Reason Access violation Source File, Line No. N/A Stack Trace msvcrt.dll + 0xa51d (0x76e3a51d) msvcrt.dll + 0xa492 (0x76e3a492) msvcrt.dll + 0xa589 (0x76e3a589) FileImpl::Write [mozilla/xpcom/obsolete/nsIFileStream.cpp, line 453] nsOutputStream::write [mozilla/xpcom/obsolete/nsFileStream.cpp, line 131] nsParseNewMailState::AppendMsgFromFile [mozilla/mailnews/local/src/nsParseMailbox.cpp, line 2199] nsParseNewMailState::MoveIncorporatedMessage [mozilla/mailnews/local/src/nsParseMailbox.cpp, line 2304] nsParseNewMailState::ApplyFilterHit [mozilla/mailnews/local/src/nsParseMailbox.cpp, line 1892] nsMsgFilterList::ApplyFiltersToHdr [mozilla/mailnews/base/search/src/nsMsgFilterList.cpp, line 372] nsParseNewMailState::ApplyFilters [mozilla/mailnews/local/src/nsParseMailbox.cpp, line 1788] nsParseNewMailState::PublishMsgHeader [mozilla/mailnews/local/src/nsParseMailbox.cpp, line 1712] nsPop3Sink::IncorporateComplete [mozilla/mailnews/local/src/nsPop3Sink.cpp, line 895] nsPop3Protocol::HandleLine [mozilla/mailnews/local/src/nsPop3Protocol.cpp, line 3430] nsPop3Protocol::RetrResponse [mozilla/mailnews/local/src/nsPop3Protocol.cpp, line 3207] nsPop3Protocol::ProcessProtocolState [mozilla/mailnews/local/src/nsPop3Protocol.cpp, line 3861] nsMsgProtocol::OnDataAvailable [mozilla/mailnews/base/util/nsMsgProtocol.cpp, line 350] nsInputStreamPump::OnStateTransfer [mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 494] nsInputStreamPump::OnInputStreamReady [mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 398] nsInputStreamReadyEvent::EventHandler [mozilla/xpcom/io/nsStreamUtils.cpp, line 217] SHELL32.dll + 0x5e0c24 (0x778b0c24) 0x2e02e804 0xfffdfcfc

=> topcrash - easily in top 10 based on stats in smartanalysis. find "3 msvcrt.dll" at http://talkback-public.mozilla.org/reports/thunderbird/TB20014/smart-analysis.all - though not clear all might be 2G related Also unclear how to interpret talkback smart analysis indicates ~540 crashes in a 1 day period (as subset of all msvcrt.dll crashes), but http://talkback-public.mozilla.org/reports/thunderbird/ indicates only 1074 crashes in a 10 day period.

I am not sure the patch fixes exactly this issue, but nsFileStream::Write() should be use PRUint32 instead of PRInt32.

(In reply to comment #13) > Created an attachment (id=334213) [details] > Proposed patch > > I am not sure the patch fixes exactly this issue, but nsFileStream::Write() > should be use PRUint32 instead of PRInt32. > If use PRUint32 instead of PRInt32, will it crash on inbox files greater than 4GB?

(In reply to comment #14) > > I am not sure the patch fixes exactly this issue, but nsFileStream::Write() > > should be use PRUint32 instead of PRInt32. > > > > If use PRUint32 instead of PRInt32, will it crash on inbox files greater than > 4GB? I am not sure 4GB over inbox causes crash or not, but anyway 4GB does not support even if PRUin32. I think Thunderbird 2.x does not support 4GB over inbox, is it?

Comment on attachment 334213 [details] [diff] [review] Proposed patch I don't think we ever write over 2GB of data at any given time, so although this patch looks OK, I don't think it will fix anything. In other words, this deals with length of the data written, not the total size of the file. Or am I missing something?

Yes, you are right. I think so too. Thunderbird does not write such huge data at a time.

Comment on attachment 334213 [details] [diff] [review] Proposed patch It sounds like we have no belief that this bug will fix anything, so setting approval- for the branch.

the windows version I think has this problem with inbox sizes. The Thunderbird Inbox is simply a huge text file, so it can be edited with a programmer's text editor. as a result of the need, I wrote a command-line mailbox splitter program at http://jesusnjim.com/code/tbird-2gb.html there are also links to articles which describe the problem in detail and how to resolve it. actually, the filesize limit is 2^32-1=2GiB-1=2147483647 I think, just like the firefox browser filesize limitation. somebody used a 32-bit int or a long for the filesize or something like that instead of a long long (gcc) or a __int64 (MINGW, borland, MSVC++). however, on MinGW compiler which is a gcc variant, it does not natively support __int64 so you must do something like /*detect MinGW compiler and if it is*/ #if defined(__MINGW32__) #include <basetsd.h> /* defines __int64. not needed for borland, MSVC++ */ typedef __int64 qlong; /* now define a printf format string we can use */ #define QLPRINTF "%I64d" #elif defined(__BORLANDC__)||defined(_MSC_VER) typedef __int64 qlong; /* now define a printf format string we can use */ #define QLPRINTF "%I64d" #elif defined(LINUX) typedef long long qlong; /* now define a printf format string we can use */ #define QLPRINTF "%lld" #elif defined(__DJGPP__) typedef long long qlong; /* now define a printf format string we can use */ #define QLPRINTF "%lld" #endif your mileage will vary for your distribution/build of linux depending on what -D options you have on gcc/g++, it may not use LINUX #define. check your build scripts and makefiles.

Comment on attachment 334213 [details] [diff] [review] Proposed patch jim: so, we (mozilla) already know how to use big files in gecko. The first problem is that mail (a different "we", and I'll generally exclude myself from it...) is using an old (and deprecated) class. + if (destFile->write(m_ibuffer, nRead) != nRead) { destFile->close(); // truncate destination file in case message was partially written // ### how to do this with a stream? destFileSpec.Truncate(newMsgPos); # xpcom/obsolete/nsFileSpecImpl.cpp * line 460, as member of class nsFileSpecImpl -- NS_IMETHODIMP nsFileSpecImpl::Truncate(PRInt32 aNewLength) So this means that if we don't crash (we might, we might not), we will probably eat all data in the file. Which is definitely wrong.

->WFM as thunderbird3 is no longer using nsFileSpec