533313 - orkinHeap::Alloc doesn't handle oom (_CxxThrowException) crash in std::bad_alloc after running for a few minutes - news related

Status: RESOLVED DUPLICATE of bug 204143

(MailNews Core :: Database, defect)

Description

[Nik B.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: 

A few minutes after startup, Thunderbird 3.0 RC2 will begin allocating memory until it bumps up against 2GB, at which point it crashes.

The CrashReporter tool complains that it cannot send the report.

All plugins/add-ons have been removed and this error occurs even in safe mode.



Reproducible: Always

Steps to Reproduce:
1. Start Thunderbird 3 RC2
2. Wait
Actual Results:  
Thunderbird crashed. The Mozilla CrashReporter tool came up, but was unable to send a crash report.


I attached TBird with Visual Studio, and waited until it crashed. 

"Unhandled exception at 0x76f898f6 in thunderbird.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x003af134."

I will try to grab a call stack and update this bug report.

Comment 1

[Nik B.]

I just used the mozilla symbol server to get the call stack of the crash in question. Sorry for the weird line-wrapping.

>	KernelBase.dll!_RaiseException@16()  + 0x58 bytes	
 	mozcrt19.dll!_CxxThrowException(void * pExceptionObject=0x0100f1ec, const _s__ThrowInfo * pThrowInfo=0x6b39ba44)  Line 161
 	mozcrt19.dll!operator new(unsigned int size=113244)  Line 61
 	thunderbird.exe!orkinHeap::Alloc(nsIMdbEnv * mev=0x0531da38, unsigned int inSize=113244, void * * outBlock=0x0100f224)  Line 91
 	thunderbird.exe!morkZone::zone_new_hunk(morkEnv * ev=0x0531da10, unsigned int inSize=113236)  Line 267
 	thunderbird.exe!morkZone::zone_new_chip(morkEnv * ev=0x0531da10, unsigned int inSize=113236)  Line 312
 	thunderbird.exe!morkZone::ZoneNewChip(morkEnv * ev=0x0531da10, unsigned int inSize=113235)  Line 359 + 0xc bytes
 	thunderbird.exe!morkPool::NewAnonAtom(morkEnv * ev=0x0531da10, const morkBuf & inBuf={...}, unsigned int inForm=0, morkZone * ioZone=0x050b40ec)  Line 466 + 0xc bytes
 	thunderbird.exe!morkStore::YarnToAtom(morkEnv * ev=0x03e37640, const mdbYarn * inYarn=0x00000000, int createIfMissing=1)  Line 733 + 0x14 bytes
 	thunderbird.exe!morkBuilder::OnValue(morkEnv * ev=0x0531da10, const morkSpan & inSpan={...}, const morkBuf & inBuf={...})  Line 856
 	thunderbird.exe!morkParser::ReadCell(morkEnv * ev=0x0000003d)  Line 593
 	thunderbird.exe!morkParser::ReadRow(morkEnv * ev=0x0531da00, int c=91)  Line 677 + 0x8 bytes
 	thunderbird.exe!morkParser::ReadContent(morkEnv * ev=0x0531da10, unsigned char inInsideGroup='')  Line 1428
 	thunderbird.exe!morkParser::ReadGroup(morkEnv * mev=0x6b852f27)  Line 1222
 	thunderbird.exe!morkParser::ReadAt(morkEnv * ev=0x0531da10, unsigned char inInsideGroup=0)  Line 1254
 	thunderbird.exe!morkParser::ReadContent(morkEnv * ev=0x0531da10, unsigned char inInsideGroup=0)  Line 1439 + 0xc bytes
 	thunderbird.exe!morkParser::OnPortState(morkEnv * ev=0x0531da10)  Line 1473 + 0xa bytes
 	thunderbird.exe!morkParser::ParseLoop(morkEnv * ev=0x0531da10)  Line 1531 + 0x8 bytes
 	thunderbird.exe!morkParser::ParseMore(morkEnv * ev=0x0531da10, int * outPos=0x0100f3c8, unsigned char * outDone=0x02ac9c78, unsigned char * outBroken=0x02ac9c79)  Line 1571
 	thunderbird.exe!morkThumb::DoMore_OpenFileStore(morkEnv * ev=0x0531da10)  Line 479
 	thunderbird.exe!morkThumb::DoMore(morkEnv * ev=0x0531da10, unsigned int * outTotal=0x0100f480, unsigned int * outCurrent=0x0100f488, unsigned char * outDone=0x0100f4a3, unsigned char * outBroken=0x0100f4a7)  Line 402
 	thunderbird.exe!morkThumb::DoMore(nsIMdbEnv * mev=0x0531da38, unsigned int * outTotal=0x0100f480, unsigned int * outCurrent=0x0100f488, unsigned char * outDone=0x0100f4a3, unsigned char * outBroken=0x0100f4a7)  Line 194
 	thunderbird.exe!nsMsgDatabase::OpenMDB(const char * dbName=0x00a99ee8, int create=0)  Line 1141 + 0x1b bytes
 	thunderbird.exe!nsMsgDatabase::Open(nsILocalFile * aFolderName=0x02ac9b80, int aCreate=0, int aLeaveInvalidDB=0)  Line 1017 + 0x10 bytes
 	thunderbird.exe!nsMsgDBService::OpenFolderDB(nsIMsgFolder * aFolder=0x0697b040, int aLeaveInvalidDB=0, nsIMsgDatabase * * _retval=0x0697b054)  Line 142
 	thunderbird.exe!nsMsgNewsFolder::GetDatabase()  Line 299
 	thunderbird.exe!nsMsgDBFolder::ApplyRetentionSettings(int deleteViaFolder=0)  Line 4720 + 0x5 bytes
 	thunderbird.exe!nsMsgNewsFolder::ApplyRetentionSettings()  Line 1855
 	thunderbird.exe!nsMsgPurgeService::PerformPurge()  Line 252
 	xpcom_core.dll!nsTimerImpl::Fire()  Line 420 + 0x6 bytes
 	xpcom_core.dll!nsTimerEvent::Run()  Line 514
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0100f878)  Line 522
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00000001, int mayWait=1)  Line 236 + 0xd bytes
 	thunderbird.exe!nsBaseAppShell::Run()  Line 170 + 0x9 bytes
 	thunderbird.exe!nsAppStartup::Run()  Line 194
 	thunderbird.exe!XRE_main(int argc=1, char * * argv=0x02a1c090, const nsXREAppData * aAppData=0x02a163c0)  Line 3323
 	thunderbird.exe!NS_internal_main(int argc=1, char * * argv=0x02a1c090)  Line 104
 	thunderbird.exe!wmain(int argc=44155024, wchar_t * * argv=0x02a1a700)  Line 112
 	thunderbird.exe!__tmainCRTStartup()  Line 591 + 0x19 bytes

Incidentally, it appears that CrashReporter fails because with all 2GB of the memory available to userspace applications taken up, there isn't anything left to actually let us write the minidump file out.

Comment 2

[Nik B.]

(And by that of course, the 2GB available to thunderbird.exe; the part of breakpad running inside tb can't write the minidump before launching CrashReporter)

Comment 3

[Wayne Mery (:wsmwk)]

(ignoring the lack of crash report ATM)

do you crash if started in safe mode?
if you start with a new profile and specific accounts not defined? (for example news)

Comment 4

[Nik B.]

I'm not sure what you mean "ignoring the lack of crash report." As I explained, FF bumps up against the 2GB per-process memory limit, so the in-process component that tries to write out the mini-dump before calling Crash Reporter fails.

My first thought was that some plugin was the fault, so I disabled all of them and the crashes continued.

To answer your first question, it did crash while starting in safe mode. 

As for the second question I did not try to do this with a new profile. However I suspect that would have worked because before reading this thread and on a hunch from the call stack I deleted my News account and the problem went away.

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to comment #4)
> 
> As for the second question I did not try to do this with a new profile. However
> I suspect that would have worked because before reading this thread and on a
> hunch from the call stack I deleted my News account and the problem went away.

so a bad news file?

Comment 6

[Nik B.]

I'm marking this as "RESOLVED/FIXED" after Wayne Mery asked me to close this. I don't necessarily know that it's been resolved, since I no longer use TB for news.

However, I'm pretty sure that the secondary bug here, namely CrashReporter itself crashing when the process has exhausted its 2GB user-mode memory space, still lurks.

Comment 7

[Wayne Mery (:wsmwk)]

bug 204143 crash, orkinHeap::Alloc uses new and throws on failure, oom

the crashreporter crashing in OOM situations is being dealt with by Ted in various bugs