InternetSearchDataSource::mTimer, a static nsCOMPtr, is held past XPCOM shutdown. See \mozilla\xpfe\components\search\src\nsInternetSearchService.cpp. See bug 43561 for more info.

Let's have this bug also cover: InternetSearchDataSource::categoryDataSource (an RDFXMLDataSourceImpl) InternetSearchDataSource::mLocalStore (a LocalStoreImpl)

The RDFXMLDataSourceImpl is responsible for leaking a lot of strings. This is a major one for the leak stats.

This is probably the biggest holding of XPCOM objects past XPCOM shutdown. Giving it to waterson, cc:ing rjc (perhaps it should be the other way around).

Now I'm not seeing this. I saw it this morning in the same build. Maybe it's intermittent.

rjc, this is probably something you can fix better than I can.

I think this actually only happens when something else is leaked. But, static nsCOMPtrs are bad anyway because they will mess with XPCOM objects after XPCOM shutdown. Right?

For |InternetSearchDataSource|, I believe that categoryDataSource, mLocalStore, and mTimer are all null'ed out in its destructor. Ref: http://lxr.mozilla.org/seamonkey/source/xpfe/components/search/src/nsInternetSea rchService.cpp#651 so if the destructor isn't being called, perhaps the whole datasource is leaking due to an extra reference somewhere else?

dbaron, do you still see these leaks? XUL documents were leaking for a while but I believe those leaks have been plugged which should have plugged these leaks as well.

No, I don't see this anymore. But should you really be using static nsCOMPtrs?

I'm not aware of anything wrong with using static nsCOMPtr<>s as long as they are nsnulled out (i.e. cleared) in the classes destructor from which they were created, for example.

mass-verifying WorksForMe bugs which haven't changed since 2001.12.31. set your search string in mail to "EmperorLondoMollari" to filter out these messages.