Whenever I try to open a new mail message, I get a crash (assertion failure) deep in the guts of some database initialization code. Steps to reproduce: 1. Erase c:\winnt\mozregistry.dat 2. rm -r \mozilla\dist\Users50 3. apprunner -installer 4. Select a profile and click Start. 5. After browser window opens, chose File->New->Mail Message. At this point I get a crash with this stack trace: NTDLL! 77f76148() nsDebug::Assertion(const char * 0x02108be8, const char * 0x02108b04, const char * 0x02108adc, int 0x0000004a) line 181 + 13 bytes mork_assertion_signal(const char * 0x02108be8) line 74 + 31 bytes morkEnv::NewError(const char * 0x02bef240) line 365 + 19 bytes morkFile::NewFileErrnoError(morkEnv * 0x02bef530) line 268 morkStdioFile::new_stdio_file_fault(morkEnv * 0x02bef530) line 664 morkStdioFile::OpenStdio(morkEnv * 0x02bef530, const char * 0x02bef410, const char * 0x02108df8) line 735 morkStdioFile::morkStdioFile(morkEnv * 0x02bef530, const morkUsage & {...}, nsIMdbHeap * 0x02befa40, nsIMdbHeap * 0x02befa40, const char * 0x02bef410, const char * 0x02108df8) line 689 morkStdioFile::OpenOldStdioFile(morkEnv * 0x02bef530, nsIMdbHeap * 0x02befa40, const char * 0x02bef410, unsigned char 0x00) line 367 + 62 bytes morkFile::OpenOldFile(morkEnv * 0x02bef530, nsIMdbHeap * 0x02befa40, const char * 0x02bef410, unsigned char 0x00) line 174 + 21 bytes orkinFactory::OpenOldFile(nsIMdbEnv * 0x02bef498, nsIMdbHeap * 0x02befa40, const char * 0x02bef410, unsigned char 0x00, nsIMdbFile * * 0x0012e67c) line 308 + 21 bytes nsMsgFolderCache::OpenMDB(const char * 0x02befa78, int 0x00000001) line 255 + 34 bytes nsMsgFolderCache::Init(nsMsgFolderCache * const 0x02befc70, nsIFileSpec * 0x02bef820) line 360 + 23 bytes nsMsgMailSession::GetFolderCache(nsMsgMailSession * const 0x028d7740, nsIMsgFolderCache * * 0x0012e770) line 167 nsMsgDBFolder::ReadDBFolderInfo(int 0x00000000) line 191 + 36 bytes nsImapMailFolder::UpdateSummaryTotals(nsImapMailFolder * const 0x02beeb8c, int 0x00000000) line 722 nsImapMailFolder::GetSubFolders(nsImapMailFolder * const 0x02beeb8c, nsIEnumerator * * 0x0012e834) line 349 nsMsgFolderDataSource::createFolderChildNode(nsIMsgFolder * 0x02beeb8c, nsIRDFNode * * 0x0012e914) line 1005 + 36 bytes nsMsgFolderDataSource::createFolderNode(nsIMsgFolder * 0x02beeb8c, nsIRDFResource * 0x01e4e2e0, nsIRDFNode * * 0x0012e914) line 794 + 16 bytes nsMsgFolderDataSource::GetTarget(nsMsgFolderDataSource * const 0x02be0120, nsIRDFResource * 0x02beeb80, nsIRDFResource * 0x01e4e2e0, int 0x00000001, nsIRDFNode * * 0x0012e914) line 228 + 25 bytes CompositeDataSourceImpl::GetTarget(CompositeDataSourceImpl * const 0x02be08f0, nsIRDFResource * 0x02beeb80, nsIRDFResource * 0x01e4e2e0, int 0x00000001, nsIRDFNode * * 0x0012e914) line 614 + 28 bytes RDFGenericBuilderImpl::IsEmpty(nsIContent * 0x02bdfde0, nsIRDFResource * 0x02beeb80) line 2466 + 65 bytes RDFGenericBuilderImpl::IsTemplateRuleMatch(nsIContent * 0x02bdee90, nsIRDFResource * 0x01e4e2e0, nsIRDFResource * 0x02beeb80, nsIContent * 0x02bdfde0, int * 0x0012ebd4) line 1393 + 19 bytes RDFGenericBuilderImpl::FindTemplate(nsIContent * 0x02bdee90, nsIRDFResource * 0x01e4e2e0, nsIRDFResource * 0x02beeb80, nsIContent * * 0x0012ec30) line 1489 + 33 bytes RDFGenericBuilderImpl::CreateWidgetItem(nsIContent * 0x02bdee90, nsIRDFResource * 0x01e4e2e0, nsIRDFResource * 0x02beeb80, int 0xffffffff, int 0x00000000) line 1896 + 44 bytes RDFGenericBuilderImpl::CreateContainerContents(nsIContent * 0x02bdee90, nsIRDFResource * 0x02bdafe0, int 0x00000000) line 2157 + 36 bytes RDFGenericBuilderImpl::CreateContents(RDFGenericBuilderImpl * const 0x02be0d40, nsIContent * 0x02bdee90) line 690 + 23 bytes RDFXULBuilderImpl::CreateChildrenFromGraph(nsINameSpace * 0x02b64fd0, nsIRDFResource * 0x02a2dbe0, nsIContent * 0x02bdee90, int 0x00000000) line 748 + 39 bytes RDFXULBuilderImpl::CreateChildrenFromGraph(nsINameSpace * 0x02b64fd0, nsIRDFResource * 0x02a28a70, nsIContent * 0x02bd97f0, int 0x00000000) line 717 + 42 bytes RDFXULBuilderImpl::CreateChildrenFromGraph(nsINameSpace * 0x02b64fd0, nsIRDFResource * 0x02a28f40, nsIContent * 0x02bd85e0, int 0x00000000) line 717 + 42 bytes RDFXULBuilderImpl::CreateChildrenFromGraph(nsINameSpace * 0x02b64fd0, nsIRDFResource * 0x02a0c090, nsIContent * 0x02b89de0, int 0x00000000) line 717 + 42 bytes RDFXULBuilderImpl::CreateChildrenFromGraph(nsINameSpace * 0x02b64fd0, nsIRDFResource * 0x02a0c4e0, nsIContent * 0x02b89f90, int 0x00000000) line 717 + 42 bytes RDFXULBuilderImpl::CreateChildrenFromGraph(nsINameSpace * 0x02b64fd0, nsIRDFResource * 0x029c4de0, nsIContent * 0x02b631c0, int 0x00000000) line 717 + 42 bytes RDFXULBuilderImpl::CreateRootContent(RDFXULBuilderImpl * const 0x02b63460, nsIRDFResource * 0x029c4de0) line 548 + 35 bytes XULDocumentImpl::EndLoad(XULDocumentImpl * const 0x02990160) line 2077 + 44 bytes XULContentSinkImpl::DidBuildModel(XULContentSinkImpl * const 0x02992730, int 0x00000001) line 543 CWellFormedDTD::DidBuildModel(CWellFormedDTD * const 0x02994cf0, unsigned int 0x00000000, int 0x00000001, nsIParser * 0x02992250, nsIContentSink * 0x02992730) line 287 + 20 bytes nsParser::DidBuildModel(unsigned int 0x00000000) line 526 + 55 bytes nsParser::ResumeParse(nsIDTD * 0x00000000, int 0x00000000) line 894 nsParser::EnableParser(int 0x00000001) line 620 + 15 bytes XULContentSinkImpl::UpdateOverlayCounters(XULContentSinkImpl * const 0x02992730, int 0xffffffff) line 1935 + 19 bytes XULContentSinkImpl::CloseContainer(XULContentSinkImpl * const 0x02ac61e0, const nsIParserNode & {...}) line 701 CWellFormedDTD::HandleEndToken(CToken * 0x018afee0) line 618 + 31 bytes CWellFormedDTD::HandleToken(CWellFormedDTD * const 0x02ac2aa0, CToken * 0x018afee0, nsIParser * 0x02ac7da0) line 479 + 12 bytes CWellFormedDTD::BuildModel(CWellFormedDTD * const 0x02ac2aa0, nsIParser * 0x02ac7da0, nsITokenizer * 0x02ac7900, nsITokenObserver * 0x00000000, nsIContentSink * 0x02ac61e0) line 254 + 20 bytes nsParser::BuildModel() line 942 + 34 bytes nsParser::ResumeParse(nsIDTD * 0x00000000, int 0x00000000) line 887 + 11 bytes nsParser::OnDataAvailable(nsParser * const 0x02ac7da4, nsIChannel * 0x02ac6af0, nsISupports * 0x00000000, nsIInputStream * 0x02ac6608, unsigned int 0x00008000, unsigned int 0x00004327) line 1288 + 19 bytes nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x02ac51f0, nsIChannel * 0x02ac6af0, nsISupports * 0x00000000, nsIInputStream * 0x02ac6608, unsigned int 0x00008000, unsigned int 0x00004327) line 2000 + 32 bytes nsChannelListener::OnDataAvailable(nsChannelListener * const 0x02ac6c60, nsIChannel * 0x02ac6af0, nsISupports * 0x00000000, nsIInputStream * 0x02ac6608, unsigned int 0x00008000, unsigned int 0x00004327) line 2273 nsFileChannel::OnDataAvailable(nsFileChannel * const 0x02ac6afc, nsIChannel * 0x02ac6af0, nsISupports * 0x00000000, nsIInputStream * 0x02ac6608, unsigned int 0x00008000, unsigned int 0x00004327) line 815 nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x02a52790) line 345 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x02a52794) line 144 + 12 bytes PL_HandleEvent(PLEvent * 0x02a52794) line 509 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00ab6410) line 470 + 9 bytes _md_EventReceiverProc(HWND__ * 0x003207e8, unsigned int 0x0000c0c0, unsigned int 0x00000000, long 0x00ab6410) line 938 + 9 bytes USER32! 77e713ed() 00ab6410()

cc Seth Spitzer (sspitzer@netscape.com) in case this is a dup of installer related bug for duplicate .newsrc lines that causes the same Mork file to be opened more than once (so the second fails since files get opened with exclusive write access, and therefore Mork cannot help but fail to do so).

bill, this is not a crash, it's an assertion. were you able to continue on after the assertion? changing summary to "assertion". still a valid bug. also, I don't think the compose window had anything to do with the assertion. looking at the stack, it looks like the imap assertion stack. re-assign to mscott. one dollar says its a duplicate.

The problem is that we are trying to open a mail summary file on a folder that has never been opened before. Bill try this for now: 1) Bring up messenger instead of trying to send a message from the browser. 2) open up your inbox (assuming it isn't more than 1k msgs or so otherwise you'll have to wait a while for us to build mail summary files (a one time cost)). 3) Now try clicking new message. Do you still assert in mork? I think the problem is that by going to new message from the browser before ever running messenger, we're getting into a case where we haven't opened folders before. and mork is asserting because we don't have a summary file for the folder yet. although I'm curious as to why opening message compose would make us look at mail folders. Maybe Alec knows...I'm investigating.

Oh interesting....when we first create a mail session, we create a folder cache even if we may not use it later...(as is the case when you bring up message compose directly from the browser)

adding david because he did the folder cache stuff. This would probably get fixed if I actually got off my butt and made the account manager a service.

No, it's not trying to open a mail database, but rather, the one and only folder cache. Usually when this fails, it's because there's no user profile directory.

Yes, they were assertions. I tried skipping over them yesterday but either it failed eventually, or I got bored. I tried again today, skipped past three assertions, and things sort of worked. I saw the assertions when starting Messenger, BTW (not going straight to new-mail msg). Oh, and I didn't have an inbox, which didn't seem to be a problem when sending a new message at this point. I successfully sent my message to Bob, so do what you wish with this bug report. Thanks.

Bill, I think I know what went wrong here.... (1) You ran apprunner -installer (2) I'm guessing you already had a 5.0 profile set up. The installer doesn't do anything if you already have a 5.0 profile. So basically, your mail prefs from 4.5 never got migrated at all! (3) You then launched mail and asserted trying to open a non-existent folder cache because nothing got initialized. To test this theory, can you try: 1) delete your mozregistry.dat (this makes us forget that you have any profiles already in 5.0) 2) Now run apprunner -installer. Select a 4.5 profile to migrate and run. Do you still see the assert? David B. Can we create a folder summary file from scratch if there isn't one already instead of falling into mork and asserting because it doesn't exist?

in addition to removing the moz registry, if you plan to migrate twice, move the old profile directory Users50/law, for example, to the side. you don't want to stop on top of it. there's a bug out on this, and the solution will be to pick a unique name so you can't stomp, even if you try.

Again, this isn't a folder summary file - it's the folder cache! And yes, we can create one if it doesn't exist. We used to, but I think maybe it got broken when MDB changed the way files got opened. I'll see if I can trick Mork.

changing summary - this has nothing to do with imap.

fixed in nsMsgFolderCache.cpp

*** Bug 12017 has been marked as a duplicate of this bug. ***

Passed by retest on the 10-08-12-M11 commercial build on all the Win98, WinNT, Mac & Linux platforms: No crash anymore when open the compose window from File-> New Message.