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.
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)
You need to log in before you can comment on or make changes to this bug.