Closed Bug 13983 Opened 25 years ago Closed 25 years ago

assertion opening folder cache.

Categories

(MailNews Core :: Database, defect, P3)

Product:
MailNews Core
Component:
Database
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: law, Assigned: Bienvenu)

References

Details

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).
Assignee: davidmc → mscott
Summary: Crash trying to compose new mail msg → assertion in imap.
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.
Status: NEW → ASSIGNED
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.
Assignee: mscott → bienvenu
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: M12
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.
Summary: assertion in imap. → assertion opening folder cache.
changing summary - this has nothing to do with imap.
Blocks: 11091
QA Contact: lchiang → huang
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Target Milestone: M12 → M11
fixed in nsMsgFolderCache.cpp
*** Bug 12017 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
OS: Windows NT → All
Hardware: PC → All
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.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.