Fixing leaks
Lately, I've been running debug builds of Firefox with trace-refcnt summaries enabled and reporting any leaks I can reproduce. Frequently, someone else quickly attaches a patch, but in the case of bug 401393, nobody else could reproduce the leak I was seeing. For me, simply loading a page with Flash and scrolling down could leak several objects.
Boris helped me use more detailed trace-refcnt logging options to figure out what caused the leak, and then Jonas assigned the bug to me:
Jesse, here's your first blocker :)
Let me know if you need help and I'll do my best.
I was able to fix the leak, although I still don't understand much of the code for the class I modified. Boris and I also figured out why not everyone could reproduce the leak: it only happened because I was using Greasemonkey, which implements nsIContentPolicy using JavaScript. (Adblock Plus does the same, and it is apparently the most popular Firefox extension, so I'm glad this leak is fixed!)
Knowing how to debug leaks with trace-refcount logging turned out to be useful: I was able to fix a few editor leaks and debug another.
December 28th, 2007 at 3:19 am
Jesse you’re a complete legend.
Thanks for this excellent work. Unfortunately it’s largely invisible to the user however that does not mean it is less meaningful than a UI tweak. It is more so. Personally I really enjoy reading posts that point out the normally invisible fixes that will make such a difference.
Thanks again
December 28th, 2007 at 7:03 am
It would be awesome if you’d document the stuff you learned from Boris and Jonas somewhere. Is using tracerefcnt hard? Are there any good docs out there on this?
December 28th, 2007 at 8:39 am
Unfortunately, based on my experience, bugs that no one else can reproduce seem to be fairly common. This can happen even with a new profile, and unlike this case, usually the cause is never found.
There are also problems with user support and standard bug reporting procedures, at least as far as the public is told. The public is discouraged from reporting bugs when used with themes and extensions. The addon is almost always blamed unless someone tracks the problem down from inside the code.
It still seems like each new release breaks something. I don’t know what to suggest. I just think it’s worth pointing out. This stuff is so complicated and poorly understood that I sometimes wonder why it works at all.
December 28th, 2007 at 6:05 pm
Using trace-refcnt summaries just to see whether you’re leaking is really easy. Just set XPCOM_MEM_LEAK_LOG to 2 and run a debug build of Firefox. It’s a great way for non-developers to find medium-sized leak bugs.
Using trace-refcnt logging to figure out why you’re leaking is a little tricker, but if I can figure it out, I’m sure you can, too ;) How to find leaks of XPCOM objects is mostly about trace-refcnt and covers all the tricks Boris told me about in the bug.
I’ve been trying to fix up the main leak tool overview wiki page, but since I only barely know what I’m talking about, this is difficult ;)
December 28th, 2007 at 6:11 pm
Hmm, How to find leaks of XPCOM objects doesn’t mention fix-macosx-stack.pl and fix-linux-stack.pl. Those are kinda important.