400926 - Occasional "leaks" of nsSimpleNestedURI instances

Status: RESOLVED DUPLICATE of bug 403199

(Core :: Networking, defect)

Description

[Jeff Walden [:Waldo]]

I inconsistently get a "leak" of an nsSimpleNestedURI reported when running with XPCOM_MEM_LEAK_LOG=1.  I can make it happen, slightly reliably, by running the RLk test and closing the window as it's loading.

Looking at a leaked instance in one case, the nsSimpleURI from which it inherits represents about:blank.  The mInner nsCOMPtr<nsIURI> member has the extremely odd value of 0x7d0.  mRefCnt is 1.

More interestingly, however, is the refcount log.  When I look at it for the leaked pointer, I see an equal number of AddRefs and Releases.  Reading the filtered output of addrefs and releases, however, shows that the reference count is doing some funky stuff: it's sometimes changing not by ±1 but by ±2.  I looked at the AddRef/Release implementations; they call the ones on nsSimpleURI, which is an aggregated class.  The macros are in <xpcom/base/nsAgg.h>, and they don't do anything atomically -- but they don't include single-thread assertions.  I think nsSimpleNestedURI may be used on multiple threads, and sometimes, if you lose, the reference count gets out of whack with reality.

nsSimpleNestedURI and nsSimpleURI don't do anything in their destructors, so the data at the pointer is probably just there because it hasn't been overwritten.  The release implementation "stabilizes" mRefCnt to 1 when it decrements to 0 (after logging), so the 1 value is consistent with the above guesses.

I don't know that this is what's wrong, but it might be.  Adding some assertions would probably verify the multi-threaded part fairly quickly, and some manual testing might be enough to say that that causes the "leak".