Congratulation on starting this memory leak roundup.

How about running static code analyzers as well on Mozilla code? This may sound a bit old fashioned however testing for bugs is rather limited by test-cases, scenarios and tools available. Running static code analyzer can probably be worth trying along with these.

First of all, you’re using a recent trunk version of Firefox, right? Because looking for leaks in Firefox 2 is more or less pointless at this time :)

For large increases in memory usage, an easy test is to do is to do the same thing (open a tab, load the page in question, close the tab) five or ten times, watching memory usage. Does memory use keep going up, or does it level off? If it levels off, it’s not a leak, and is probably caching or malloc fragmentation.

If you see that memory usage keeps going up, there’s a good chance you’ve found a leak. You could file a bug report at this point, noting that memory use keeps going up, but the bug is more likely to be fixed quickly if you include information from one of our leak tools showing that it’s definitely a leak.

If leak-gauge.pl or trace-refcnt or trace-malloc says what objects leak, you have a great bug report and it’s very likely to be fixed before we ship Firefox 3. leak-gauge.pl is pretty easy to run but only finds certain large leaks; the others are progressively harder to run and find progressively “smaller” leaks.

If none of those tools shows a leak, it could still be a leak-until-shutdown. These bugs are harder to diagnose; I think the preferred tool is diffbloatdump.pl (which requires a trace-malloc build).

Having simple steps-to-reproduce is important, too. Having a simple testcase is nice but isn’t as important for leak bugs as it is for most other types of bugs.

I have a question whether some stuff is regarded as a memory like by the Firefox developers:

If you open a tab, browser around a bit and then close a tab, the Firefox process is consuming more memory then before the tab was opened (even with browser.sessionhistory.max_total_viewers set to 0).

Does this mean Firefox is leaking memory? Or are the other reasons memory consumption could have increased (loaded plugins)?

Submitted my first mlk bug last night with help from people in #developers on irc.mozilla.org

Dave Townsend pointed out this:

Environment variables affecting crash reporting

Which helped me get over a stumbling block where Breakpad kicked in every time I tried to run the latest nightly with the NSPR environment variables. I added this:

SET MOZ_CRASHREPORTER_DISABLE

to the start of my batch file to do the trick.

Also pointing out was this Debugging memory leaks document. However would I be right in assuming the tips in this document require C++ programming skills to implement?

Please vote for my bug :)