994412 - Automatically enable refcount logging for rooting objects in shutdown cycle collection

Status: RESOLVED INACTIVE

(Core :: Cycle Collector, task)

Description

[Andrew McCreight [:mccr8]]

One annoying problem with investigating quasi-leaks where we run an extra shutdown CC is that oftentimes the rooting reference never shows up in the CC graph.  Instead, the Unlink of an object in the first CC will only indirectly cause the release of one of the rooted objects.

You can do this manually by setting breakpoints, maybe running a CC log analysis, etc. but I decided to create a more automated approach that does the following:

1. Produce a cycle collector log as usual.
2. Start a python process that runs the find_roots script on the CC log that was just produced to determine the address of every object that is keeping an nsGlobalWindow alive, then write that to a file.
3. Load that second file, and then start refcounting every one of these objects, using the function in bug 974187.

Then you continue shutting down as normal, which produces a refcount log of the rooting objects.

The actual command line I used, which sets up refcount logging and cycle collector logging in the right way, is this:
XPCOM_MEM_LOG_CLASSES=nsXULElement XPCOM_MEM_REFCNT_LOG=./rclog.txt XPCOM_MEM_LOG_OBJECTS=99999 MOZ_CC_LOG_SHUTDOWN=1 MOZ_CC_LOG_THREAD=main MOZ_CC_LOG_DIRECTORY=~/logs/me/simple ./mach run -P debug

This patch is pretty hacky.  The path to the location of the heap graph script is hard coded. There's a lot of grossness around the fact that we're deep in shutdown, so many XPCOM services don't work.  And so on.

It would also be nice to stop refcount logging all of the objects we added after unlinking is complete, so we avoid the noise of edges we do know about.  The current approach requires specifying all of the classes of interest, which is not too bad, but it would be nice to provide some feedback about objects that fail to be added because there class isn't being tracked, by using the CC participant.  Another nice feature would be to just track the first handful of roots, as the more things you track the slower things will get, and there's more noise.

But anyways, it is still somewhat useful as is.  I used this to identify bug 994371.  I attached the interesting part of the refcount log for one of the objects there, which points right to the culprit in this case.

Comment 1

[Andrew McCreight [:mccr8]]

Attachment: Automatically start refcounting logging objects that are rooting in the CC graph at shutdown. WIP

Comment 2

[Adam Vandolder [:avandolder]]

Hi Andrew, this came up in today's bugbash triage and we were wondering if this is still something that should be addressed or if it can be closed now?

Comment 3

[Andrew McCreight [:mccr8]]

This is really just a task. But I think this isn't too much of an issue now. Refcount logging is very fast now, so you can just log it for the entire run and then search for the first release during the shutdown CC.