Courtesy Patrick Beard. Storing the patch as a bug because I can't commit to checking in + watching the tree just right now. Here're are patches to fix nsInterfaceInfo leaks: Index: nsInterfaceRecord.cpp =================================================================== RCS file: /cvsroot/mozilla/xpcom/reflect/xptinfo/src/nsInterfaceRecord.cpp,v retrieving revision 1.4 diff -r1.4 nsInterfaceRecord.cpp 59,61c59,60 < if (*result == NULL) { < NS_RELEASE(parent); < } else { --- > NS_IF_RELEASE(parent); > if (*result != NULL) { Since the info always holds a ref to parent, it always needs to be released here. Index: nsInterfaceInfoManager.cpp =================================================================== RCS file: /cvsroot/mozilla/xpcom/reflect/xptinfo/src/nsInterfaceInfoManager.cpp, v retrieving revision 1.38 diff -r1.38 nsInterfaceInfoManager.cpp 403a404 > NS_IF_RELEASE(value->info); Somebody needs to release this. You could add a destructor that does it. - Patrick

Fix checked in, with some changes to account for internal refcount knowledge. We're still leaking one nsISupports from xpctest_echo.js, and currently 6 nsInterfaceInfoes from several page views in the browser. Not so bad... Keeping the bug open and marking it assigned to track that leak.

Confirmed that the leaks have stopped showing up in viewer. Thanks.

A run of the browser leaks (among others) an nsINetNotify nsInterfaceInfo. The calling function when that info is built is nsProxyEventClass::GetNewOrUsedClass, which addrefs the info while doing an isISupportsDescendent check. (John, is that functionality exposed in xpconnect?) Doug tells me that Everything's Changing, so I'll check back after he lands.

Moving all XPConnect QA contact to rginda

marking fixed. xptinfo has been rewritten. Thre are no known *direct* leaks of its objects in the users of the system.