1254278 - XPCOM_MEM_LOG_CLASSES=nsTArray_base does not report stacks properly

Status: RESOLVED DUPLICATE of bug 1505294

(Core :: XPCOM, defect)

Description

[Andrew McCreight [:mccr8]]

qDot attempted to use XPCOM_MEM_LOG_CLASSES=nsTArray_base, but found that it was generating megabytes and megabytes of stacks, even though only a few were actually leaking.

nsTArray_base uses  MOZ_COUNT_CTOR/DTOR, which uses a slightly different mechanism than the refcounted objects I've seen the stack stuff used with before, so it isn't too surprising that there's an error there.

Comment 1

[Andrew McCreight [:mccr8]]

I couldn't reproduce with the case of a trivial class that does MOZ_COUNT_CTOR/DTOR, so there's more going on than that. I can reproduce with nsTArray_base.

I added two assertions to GetSerialNumber(), one that checks that we only find an existing serial number when aCreate is false... but that ends up triggering fairly early. I'm not sure what is going on.

The top of the stack looks like this:

GetSerialNumber(void*, bool) + 1586 (nsTraceRefcnt.cpp:615)
NS_LogCtor + 255 (nsTraceRefcnt.cpp:1211)
PLDHashTable::Add(void const*, mozilla::fallible_t const&) + 316 (PLDHashTable.cpp:584)
PLDHashTable::Add(void const*) + 15 (PLDHashTable.cpp:594)
nsChromeRegistryChrome::ManifestOverlay(nsChromeRegistry::ManifestProcessingContext&, int, char* const*, int) + 277 (nsChromeRegistryChrome.cpp:621)

Comment 2

[Andrew McCreight [:mccr8]]

I think bug 1505294 has some more information on what looks like the same issue.