The attached annotated stack crawl shows the allocation point of a leaked morkPool object. I haven't a clue how or why this leaks, but it consistently does. The URL above is a CVS blame URL for the allocation point of the object itelf.

Hey Dave, do you have an ETA on these? Thanks, Warren

See http://bugzilla.mozilla.org/show_bug.cgi?id=15598 for a long explanation. If you agree, we can mark this one a duplicate. Environments were designed to leak. When folks decided on a goal of no leaks, we did a lot of work to enable such a thing, but we stopped short of total follow through, for reasons best recalled by David Bienvenu.

I don't understand why anything would be designed to leak. Let's look into fixing this. Thanks.

I don't think it will be fixed. It might be easier to understand after reading http://bugzilla.mozilla.org/show_bug.cgi?id=15598. The basic idea is that there should be very few of them, and they should be re-used. They were only designed to leak after the retarded XPCOM refcount model forced me to retain references to environments in my objects, in order to simultaneously keep my runtime model and mimic an XPCOM interface desired by David Bienvenu for addref and release, when neither of these take any closure arguments (which is the stupid part, just like C++ destructors). The design to leak aspect was the last straw, which happens to have the work around I described. David Bienvenu and I already put a lot of time into preparing to recover all memory allocated, but we didn't follow through for reasons David Bienvenu might know. Also, I'm not going to have time to do this since I won't be working on this much longer, so you'll need to re-assign the bug if you want someone to hack the daylights out of the existing code.

Now, here's what I should have said instead, if I was like anyone else: Oh, yes, I'll fix that very soon; I'm on top of it and there's nothing to worry about. But I have some other things I should do first, so I might not get to it right away. When I have an ETA, I'll put it in here. I actually think my honest answer is much to be preferred, but I can change to the other one if folks rather I sound nicer.

these are mine now, I guess.

moving to m17, but probably won't be fixed.

moving to future.

*** Bug 45898 has been marked as a duplicate of this bug. ***

changing priorities

leger is no longer @netscape. changing qa contact to component's default

David, is this a dup of 15598 and if not, is this leaking a lot of memory?

It could be caused by bug 15598, but I'm not sure. This actually could be a significant leak, since a pool is a variable sized chunk of memory.

marking nsbeta1-

fix is to free the pool - runs fine under purify.

Comment on attachment 52222 [details] [diff] [review] proposed fix sr=sspitzer

r=naving

fix checked in.

If this is truly fixed (and I'm sure it is), I'm going to have a hard time knowing if I've covered my bases for verification. David, any off-the-top-of-your-head ideas as to where this would've showed up easily, or should this have shown up in nearly every interaction with Mork?

yes, every time you opened a mork database, this leak should have shown up.

Okay, runs from the 9th for newsgroups don't show any stacks with 'pool', and neither do addressbook runs. Marking verified FIXED.