Leaks went up over 5KB according to the leak tests. curt, thesteve: could you please elaborate on exactly what this test is measuring? Also, if we have the raw data, could you attach to the bug?
curt, thesteve, can you provide some raw data on the leaks and attach to this bug?
The raw, raw data is really huge--so huge, in fact, it broke Steve's ananlysis tool--so rather than attach it, I think I'll just point to it: /u/curt/boehm/results/010604/gtol.LEAKS and ltog.LEAKS. These are today's results which are down about an order of magnitude from the last test we did, but about an order of magnitude greater than what we were consistantly seeing a month ago. I have been including putting these files up on ftp://ftp.mozilla.org/pub/data/leaks but they are just too darn big, even zipped, to push up there right now. If someone needs to look at them and cannot get to my home directory let me know and we'll come up with another alternative. I'll have to leave it to Steve to fill in the details of exactly what these tests are measuring.
On "what exactly this test is measuring:" This is a LINUX test, measuring gtkEmbed configured with a .mozconfig file (which I will attach to this bug.) The input data are two files from the static test suite: static41x3_gtol.list (whose output is graphed as "gtol"), and static41x3_ltog.list ("ltog"). The command line to run the gtol test is: gtkEmbed "http://intrepid/buster.cgi?interval=10&file=lists/static41x3_gtol.list" The ltog test comand line is the same, except that the list file is "static41x3_ltog.list"
I'll be attaching two files (one for the "ltog" case, the other for "gtol", which represent the output from my "leak-diff" tool prototype. This tool compares two leak files (from two different dates), and reports the new leaks. the format of the file is: `72 instances (for a total of 2016 bytes) of:` followed by the call stack. The two dates I've picked are May 9th, one of the last dates before the leaks went wild, and June 13 the last date we have an overnight build for. Each attached file reports only the 12 leading leak sites (by total bytes leaked). I've just picked these limitations: the dates and limits on number of sites reported can be changed. I'm asking for help in the part which requires some human intervention: perusing the stacks, and using addr2line to try to pick out the leak causes.
Okay, that's bug 84401. I'm going to mark this as a dup. *** This bug has been marked as a duplicate of 84401 ***