74415 - implement root detection in XPCOM_MEM_BLOAT_LOG

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect, P4)

Description

[Chris Waterson]

There's nothing magical about root detection that we couldn't do cheaply with
XPCOM_MEM_BLOAT_LOG, and thus just have as part of the tinderbox cycle.

Comment 1

[Chris Waterson]

Attachment: work-in-progress patch

Comment 2

[Chris Waterson]

A la trace-malloc and boehm-gc, maintain a table of live objects. At shutdown,
use the table to construct an object graph, dump objects without parents
(ideally after doing strongly-connected-components to handle cycles). Since
XPCOM_MEM_BLOAT_LOG doesn't track all objects, the fidelity of this approach
won't be perfect: some cycles won't be detected, some objects will be called
``roots'' that aren't really roots.

OTOH, the approach is lightweight (no special build required, only need to set
env variable to turn it on), and will work XP.

Comment 3

[Chris Waterson]

Attachment: working patch

Comment 4

[Chris Waterson]

Conditioned on XPCOM_MEM_LOG_ROOTS. Because it doesn't do SCC, it won't detect
cycles (and simply won't print them).

Comment 5

[Chris Waterson]

This will need more work to be useful. It doesn't handle nested objects. For
example:

  class A {...};
  class B {
  protected:
    A a;
  };
  B* b = new B();

If `b' is leaked, then `b.a' is considered a `root'.

Also (possibly related), needs to be taught about interior pointers (e.g., MI):

  class A : public nsIFoo, public nsIBar, public nsIBaz { ... };

  A* a = new A();
  nsIFoo* a1 = a;
  nsIBar* a2 = a;
  nsIBaz* a3 = a;

It will think a1, a2, and a3 are all different objects.

I think both these problems could be solved in the BuildObjectGraph() phase by
building a secondary object table (other than gLiveObjects) that's keyed by a
range (address + size) instead of simply a pointer.

Any objects held by our base collection classes (e.g., nsISupportsArray,
nsHashTable) will be treated as roots. I don't think we can easily fix that
within this framework, because the storage containing these pointers is ``out of
band'' from the main object that's kept in the live object table.

  - We could add more hand instrumentation that'd do the bookkeeping

  - We do more aggressive pointer-following (e.g., wrap in a signal handler,
    and recursively probe)

As it stands right now, it's marginally useful to the well-informed, because you
can begin to visualize the object structure. To the less-well-informed, it may
be somewhat harmful, and lead to wild ``bogo root'' hunts.

Comment 6

[Chris Waterson]

Project for another day.