XPCOM_MEM_LOG_CLASSES=nsTArray_base does not report stacks properly

NEW
Assigned to

Status

()

3 years ago
3 years ago

People

(Reporter: mccr8, Assigned: mccr8)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox47 affected)

Details

(Whiteboard: [MemShrink:P2])

(Assignee)

Description

3 years ago
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.
Whiteboard: [MemShrink] → [MemShrink:P2]
Assignee: nobody → continuation
(Assignee)

Comment 1

3 years ago
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.