here's the stack. I've seen it happen to mscott, as well. 00000000 PPC 0C870D88 0D444200 PPC 0C87017C main+00060 0D4441B0 PPC 0C86F9E4 main1(int, char**)+00E98 0D444010 PPC 0D685E64 nsAppShellService::Shutdown()+00034 0D443F60 PPC 0D6859D4 nsAppShellService::EnumerateComponents(void (nsAppShellService:: *)(const void*, void*, const nsID&))+00200 0D443ED0 PPC 0D685CD8 nsAppShellService::ShutdownComponent(const nsID&)+ 00054 0D443E80 PPC 0C7901F8 nsMessengerBootstrap::Shutdown()+00044 0D443E30 PPC 0D6CEEE8 nsServiceManager::UnregisterService(const char*)+ 00044 0D443DE0 PPC 0D6CE4C4 nsServiceManagerImpl::UnregisterService(const char* )+00050 0D443D90 PPC 0D6CE32C nsServiceManagerImpl::UnregisterService(const nsID& )+000A0 0D443D20 PPC 0D6C9074 nsObjectHashtable::RemoveAndDelete(nsHashKey*)+00054 0D443CD0 PPC 0D6CD75C DeleteEntry(nsHashKey*, void*, void*)+0002C 0D443C90 PPC 0C769488 nsMsgMailSession::Release()+00070 0D443C50 PPC 0C769778 nsMsgMailSession::~nsMsgMailSession()+00050 0D443C10 PPC 0C777A34 nsMsgAccountManager::WriteToFolderCache(nsIMsgFolderCache*)+0002 8 0D443BD0 PPC 0D6C85F8 nsHashtable::Enumerate(int (*)(nsHashKey*, void*, void*), void*) +0003C 0D443B90 PPC 0D7547BC PL_HashTableEnumerateEntries+00060 0D443B20 PPC 0D6C7E38 _hashEnumerate(PLHashEntry*, int, void*)+00030 0D443AE0 PPC 0C776E14 nsMsgAccountManager::hashTableWriteFolderCache(nsHashKey*, void* , void*)+00098 0D443A80 PPC 0BA04AA4 nsMsgIncomingServer::WriteToFolderCache(nsIMsgFolderCache*)+000C 8 0D443A20 PPC 0BA0C828 nsMsgDBFolder::WriteToFolderCache(nsIMsgFolderCache* )+002D0 0D443970 PPC 0BA0C828 nsMsgDBFolder::WriteToFolderCache(nsIMsgFolderCache* )+002D0 0D4438C0 PPC 0BA0C5AC nsMsgDBFolder::WriteToFolderCache(nsIMsgFolderCache* )+00054 0D443810 PPC 0B9ACDB8 nsImapMailFolder::GetSubFolders(nsIEnumerator**)+ 0005C 0D443740 PPC 0B9ABE40 nsImapMailFolder::GetPath(nsIFileSpec**)+00084 0D4436F0 PPC 0B9F8F38 nsImapURI2Path(const char*, const char*, nsFileSpec& )+00294 0D4434A0 PPC 0B9F8908 nsGetImapServer(const char*, const char*, nsIMsgIncomingServer** )+00068 0D4433F0 PPC 0D6CE988 nsServiceManager::GetService(const nsID&, const nsID&, nsISuppor ts**, nsIShutdownListener*)+0005C 0D4433A0 PPC 0D6CDD64 nsServiceManagerImpl::GetService(const nsID&, const nsID&, nsISu pports**, nsIShutdownListener*)+00118 0D443310 PPC 0D6C7018 nsComponentManager::CreateInstance(const nsID&, nsISupports*, co nst nsID&, void**)+00060 0D4432C0 PPC 0D6DE078 nsComponentManagerImpl::CreateInstance(const nsID&, nsISupports* , const nsID&, void**)+000D0 0D443260 PPC 0C767C44 nsMsgFactory::CreateInstance(nsISupports*, const nsID&, void**)+ 002A0 0D4431D0 PPC 0C76A918 NS_NewMsgMailSession+00074 0D443180 PPC 0C769BB4 nsMsgMailSession::Init()+00318 0D443040 PPC 0C79E554 nsMsgFolderCache::Init(nsIFileSpec*)+0009C 0D442FF0 PPC 0C79E41C nsMsgFolderCache::OpenMDB(const char*, int)+00548 0D442C80 PPC 0C60B158 orkinFactory::CreateNewFileStore(nsIMdbEnv*, nsIMdbHeap*, const char*, const mdbOpenPolicy*, nsIMdbStore**)+00100 0D442C10 PPC 0C634D48 morkStore::CreateStoreFile(morkEnv*, const char*, const mdbOpenP olicy*)+00054 0D442BC0 PPC 0C620FAC morkFile::CreateNewFile(morkEnv*, nsIMdbHeap*, const char*)+0002 4 0D442B80 PPC 0C6217F8 morkStdioFile::CreateNewStdioFile(morkEnv*, nsIMdbHeap*, const c har*)+00070 0D442B30 PPC 0C6223DC morkStdioFile::morkStdioFile(morkEnv*, const morkUsage&, nsIMdbH eap*, nsIMdbHeap*, const char*, const char*)+00074 0D442AF0 PPC 0C622564 morkStdioFile::OpenStdio(morkEnv*, const char*, const char*)+001 04 0D442A90 PPC 0C622304 morkStdioFile::new_stdio_file_fault(morkEnv*) const+ 00050 0D442A40 PPC 0C6213C4 morkFile::NewFileErrnoError(morkEnv*) const+00030 0D442A00 PPC 0C62015C morkEnv::NewError(const char*)+00020 0D4429C0 PPC 0C61F0F8 mork_assertion_signal(const char*)+00024 0D442980 PPC 0D6C98F8 nsDebug::Assertion(const char*, const char*, const char*, int)+0 0040

This means fopen() failed; you need to check errno, using prerror() or strerror(), or just look in morkFile::NewFileErrnoError(). When this happened to Chris Waterson, the reason was that he had not closed the file stream used to read the first 512 bytes, so it was still open when Mork tried to re-open it. If this is not the reason in this case, then it is most likely still open for some other reason -- perhaps because that particular db was already open as a store for some reason. I expect I can take no further action on this bug, since it must be unintentional pilot error to re-open a file when it is already open; so the logic for why this is wrong is somewhere above Mork. I can look at the usage point to see whether the NSPR file stream is opened in it's own block, to ensure it gets closed immediately after reading the first 512 bytes. Howeve, since I am very soon going to check in file changes that remove that sequence of events when opening a db file, that seems like a waste of time.

Seth - do you still have this problem?

Move milestone stoppers to M10

this is a dup of a fixed bug. *** This bug has been marked as a duplicate of 13983 ***

I'll have to trust david that this is a duplicate since I'm not running debug builds :-) I'll mark verified as a duplicate. If anyone disagrees, pls reopen. Thanks.