crash on shutdown in nsMsgKeySet::Output() I crashed here: s_head = (char *) nsMemory::Alloc(s_size); s_head[0] = '\0'; // otherwise, s_head will contain garbage. the Alloc() failed because s_size was bogus (too big, too small?) s_size 0x66666666 Not sure how I got into this state. The newsgroup was netscape.public.mozilla.xul, something I unsubscribed from in the current session. m_readSet looked deleted. m_data, m_data_size,m_length,m_cached_value,m_cacned_value_index of m_readSet where 0xdddddddd nsMsgKeySet::Output(char * * 0x05260930) line 322 + 3 bytes nsNewsDatabase::Commit(nsNewsDatabase * const 0x0704a690, int 2) line 202 nsMsgDatabase::CloseMDB(int 1) line 1046 nsMsgDatabase::Close(nsMsgDatabase * const 0x0704a690, int 1) line 1193 nsNewsDatabase::Close(nsNewsDatabase * const 0x0704a690, int 1) line 187 nsMsgDBFolder::Shutdown(nsMsgDBFolder * const 0x071a4a84, int 0) line 113 nsMsgDBFolder::~nsMsgDBFolder() line 105 nsMsgNewsFolder::~nsMsgNewsFolder() line 142 + 103 bytes nsMsgNewsFolder::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsRDFResource::Release(nsRDFResource * const 0x071a4a68) line 83 + 135 bytes nsMsgFolder::Release(nsMsgFolder * const 0x071a4a68) line 214 + 12 bytes nsMsgDBFolder::Release(nsMsgDBFolder * const 0x071a4a68) line 83 + 12 bytes nsMsgNewsFolder::Release(nsMsgNewsFolder * const 0x071a4a68) line 145 + 13 bytes nsCOMPtr<nsIMsgFolder>::assign_assuming_AddRef(nsIMsgFolder * 0x00000000) line 473 nsCOMPtr<nsIMsgFolder>::assign_with_AddRef(nsISupports * 0x00000000) line 915 nsCOMPtr<nsIMsgFolder>::operator=(nsIMsgFolder * 0x00000000) line 585 nsMsgDatabase::CleanupCache() line 611 msgDBModuleDtor(nsIModule * 0x01563908) line 78 nsGenericModule::Shutdown() line 323 + 10 bytes nsGenericModule::~nsGenericModule() line 234 nsGenericModule::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsGenericModule::Release(nsGenericModule * const 0x01563908) line 236 + 136 bytes nsDll::Shutdown() line 467 + 18 bytes nsFreeLibrary(nsDll * 0x01563620, nsIServiceManager * 0x00000000, int 3) line 386 nsFreeLibraryEnum(nsHashKey * 0x01563778, void * 0x01563620, void * 0x0012fe98) line 434 + 64 bytes _hashEnumerate(PLHashEntry * 0x015637c0, int 47, void * 0x0012fe7c) line 199 + 26 bytes PL_HashTableEnumerateEntries(PLHashTable * 0x002fde98, int (PLHashEntry *, int, void *)* 0x10029370 _hashEnumerate(PLHashEntry *, int, void *), void * 0x0012fe7c) line 429 + 15 bytes nsHashtable::Enumerate(int (nsHashKey *, void *, void *)* 0x1007ec10 nsFreeLibraryEnum(nsHashKey *, void *, void *), void * 0x0012fe98) line 362 + 21 bytes nsNativeComponentLoader::UnloadAll(nsNativeComponentLoader * const 0x002fd330, int 3) line 1016 nsComponentManagerImpl::UnloadLibraries(nsIServiceManager * 0x00000000, int 3) line 3022 + 28 bytes nsComponentManagerImpl::Shutdown() line 824 NS_ShutdownXPCOM(nsIServiceManager * 0x00000000) line 578 + 11 bytes main(int 2, char * * 0x00304b90) line 1813 + 8 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e87903()

I doubt I will be able to reproduce this, but I'll try. this might be a hard to reproduce bug. hammer, does it show up in talkback at all? we could check s_head after the Alloc() and return failure and handle it, but we'd be lucky if s_size was always bad. it might be random in optimized builds, instead of 0x66666666. and then after that, the deleted m_readSet might cause a further crash.

I tried to reproduce this, without any luck. Do you remember if you read news messages in this group during the session that you unsubscribed to the group? I think unsubscribe should be closing and deleting the .msf file for the group, so we should never get here at all...

We have a crash in nsMsgKeySet::GetLastMember, that is bug 141299. In the summary of that bug, it's described as 'resubscribing to previously unsubscribed group', which sounds similar to your crash. I'll grep climate.mcom.com now, and let you know what Talkback reports say.

I suspect this is a trunk only crash, and relatively new. I added code to write out the read set when a news db gets committed recently. It probably has a common cause as other crashes in this area (the db holding onto a read set which has been deleted)

http://climate/reports/VeryFastSearchStackSigNEW.cfm?stacksig=nsMsgKeySet%3A%3AOutput It's not limited to trunk-only. There have been about 18 crashers, some on the Gecko1.0 branch and a few on the MozillaTrunk.

Note that I also hit this stack whilst trying to verify/reproduce bug 127707.

the crash site is not trunk only, but the whole, complete, stack trace is trunk only (nsNewsDatabase::Commit does not call nsMsgKeySet::Output()) on the branch.

I'm going to mark this as a dup of bug 141299 and pray. *** This bug has been marked as a duplicate of 141299 ***

We can reopen this should Seth/others see it again. For now, verifying to get off my list.