I'm showing 1100 leaks at startup in a build of apprunner from the closed tree on Wednesday, 17 Mar 99, Windows build. Personally I wouldn't hold up release for that reason, but that's a number four or five times its usual size, and it is a little embarrassing.

PS - a good 3/4 of these leaks are happening in the parser, where temporary tokens created to consume attributes are dropped. I haven't traced it far enough to know if it's a problem with the token recycler or some other list where these tokens sometimes end up.

Re-assinged to chofmann@netscape.com. Chris, who the heck should get bugs like this? Who is the memory leak czar? Troy?

I've traced it a bit farther. It looks to me like the XUL document never releases its parser once it's finished fwith the chrome. Hanging onto the parser is the parser context, which holds, after processing the default M3 startup URL, three or four hundred old tokens at two heap allocations apiece. The contained HTML webshell does release its parser once all connections are complete, so it seems like a XUL-specific problem. My guess is that Chris W is aching for a shot at this one.

leaks are just like crashes as far as ownership. we need to track down specifically in the code where the leaks are comming from and the owner of that code should own the problem and fix. i.e. there is no leak czar. From some reports I saw troy and rickg ran purify just before M3 and we looked pretty leak free on viewer. I guess the next round of questions on this report are Is this apprunner specific? have we regressed in the short period between when troy and rickg ran there last analysis? Can we post a purify report or some more specifics about where the leaks reside? adding troy and rickg to the cc list.

adding the memory leak super finder to the cc list (bruce@cybersight.com) reassign to waterson for more investigation.

I put together a summary of all of these leaks. It can be found at http://www.cybersight.com/~bruce/apprunner19990328.html I'll be filing reports on the leaks that I say aren't filed yet in there. (Probably within 20 minutes). I'll update the document with the bug numbers for them at that point. Also, be sure to note that that report leaves out a very significant source of leaks that I have a work around for, but which really needs to be fixed as well. And, this is still much better than it was 3 weeks ago. As well, it should be noted that this is from my tree, which differs from the public tree where my patches haven't been committed as of yet, so results may vary somewhat.

Just changing the title to reflect the pattern I've used for all of the memory leak bugs that I've reported so far, so there is an easy way to search for them. This ties into the post that I'm about to make to the newsgroups.

What is correct eng for this? waterson or rickg? And could one of you set the Target Milestone please. Can you get this fixed for M4? Or later?

Set target milestone to M5.

I fixed a big leak where the XUL document was not releasing the parser. So I'm marking this as fixed (I'm _not_ going to own up to the other 1,100 memory leaks). ;-)

I'm not the official QA contact, but I do have the tool that originally showed all the leaks. We have a completely new set of leaks now, but the ones I was complaining about when I reported the bug are gone. Seems fair to mark the bug verified.

Actually .. the leak situation is a TON better now .. the new set of leaks appears to just be a large leak or two of something specific. A lot of good work has been done!