Leak Debugging Screencasts

L. David Baron (dbaron@dbaron.org)

I was asked to record some screencasts showing how I debug memory leaks so that other people could understand better how I use our memory leak debugging tools. So I've been recording (and talking) while I'm debugging memory leaks.

These are listed in the order I made them. Many of them probably aren't particularly interesting at all. First, I'd recommend reading the overview of our memory leak tools. Then:

The screencasts

Leak Debugging Session 1 (10 MiB, 6m24s, recorded 2007-08-29T22:03-07:00)
An attempt to debug the RLk being nonzero on the Mac tinderbox. Demonstrates basic use of XPCOM_MEM_LEAK_LOG and running the tinderbox leak test. I couldn't reproduce the leak.
Leak Debugging Session 2 (13 MiB, 8m17s, recorded 2007-08-30T12:00-07:00)
Another attempt to debug the RLk being nonzero on the Mac tinderbox. Demonstrates basic use of XPCOM_MEM_LEAK_LOG and running the tinderbox leak test. Again, I couldn't reproduce the leak.
Leak Debugging Session 3 (89 MiB, 1h00m40s, recorded 2007-08-30T17:44-07:00)
An attempt to debug bug 393898. But I made a mistake a few minutes in, as described here, and ended up debugging something that wasn't actually leaking in the case I was debugging. However, it was leaking in another important case, and I found that by code inspection, so I ended up fixing bug 342600 as a result. This shows a bit about how to look at DEBUG_CC output and quite a bit about how to poke at JavaScript objects in the debugger to figure out where they were created.
Leak Debugging Session 4 (21 MiB, 14m31s, recorded 2007-08-31T14:22-07:00)
Leak Debugging Session 5 (63 MiB, 45m49s, recorded 2007-08-31T14:43-07:00)
[Two screencasts that should have been one.] As a followup to bug 342600 comment 10, and perhaps also related to the real bug 393898, I debugged why DOM Windows didn't go away when closing the addons window. I eventually filed bug 394514 with my findings, although it's pretty closely related to the existing bug 387491. This one is probably the most confusing so far; I spent most of the time I was recording it being confused; the underlying problem is in some sense a deficiency of the cycle collector.
Leak Debugging Session 6 (43 MiB, 27m05s, recorded 2007-08-31T17:37-07:00)
This is a pretty clean demonstration of how to debug a simple leak using the refcount balancer. It involves only XPCOM_MEM_REFCNT_LOG and not XPCOM_MEM_COMPTR_LOG, though. And the leak itself is potentially a little bit confusing due to XPCOM aggregation. But it's probably a good first screencast to watch. The leak is bug 394528.
Leak Debugging Session 7 (50 MiB, 35m56s, recorded 2007-08-31T21:29-07:00)
A bunch more use of the refcount balancer. I moved more quickly through things, and used the refcount balancer in rapid succession on about 6 different objects. Probably a reasonably followup to the previous session. The leak is bug 394542.

How I made these

I installed pyvnc2swf on my Fedora 7 machine. I also needed to install pygame and tkinter RPMs for this to work. I also installed audacity (from Fedora) and lame-libs (from Livna).

Then I made the screencasts in four steps:

  1. Connected with vncviewer to the machine I was debugging on (in this case, an ssh tunnel from localhost:5900)
  2. /usr/local/pyvnc2swf-0.9.3/pyvnc2swf/vnc2swf.py -o leak6-raw.swf -S "arecord -r 22050 leak6-raw.wav" localhost:0
  3. Use audacity to convert the WAV to MP3 (File → Open; File → Export As → MP3)
  4. /usr/local/pyvnc2swf-0.9.3/pyvnc2swf/edit.py -a leak6-raw.mp3 -l -K 500 -S 1.0s -o leak6.swf leak6-raw.swf