With the Boehm collector, edward and I discovered that six nsBoxSizeListImpl objects are leaked (out of 11) as root leaks doing a clean startup/shutdown with the sidebar open. Looks like the code in here is just not freeing this stuff for some reason. Edward is doing some initial investigation: hyatt/evaughan, if you have any suggestions please chime in.
This is probably a duplicate of bug #43384 .... I think that my explanation on that bug is a possible answer .. I'll try a quick test of now.
I don't think I was right after some quick tests. but, I'm somewhat confused by what might be holding onto that list in the case where aList is nsnull. (I don't see anything holding on to it unless it is just me being too tired.)
It looked to me to be an ownership problem with nsBoxSizeList's. The function which creates the list, nsTempleLayout::GetMonumentList, causes other nsMonumentLayout objects to create nsBoxSizeLists, to store them within their own objects, then return pointers to them (effectively caching the nsBoxSizeLists in nsMonuments). When DesecrateMonuments is called, it only frees the nsBoxSizeLists that it created, and none of the ones created down the hierarchy of nsMonumentLayouts from the GetMonumentList call earlier. This is what appears to be happening to me. The question is then, when should these cached nsBoxSizeLists (stored in the mMonuments field of nsTempleLayout) be freed? At the time Release is invoked or when DesecrateMonuments is invoked? Does this look like the problem as anyone else sees it, or am I totally off mark here?
Eric has checked in a fix for this.
Assignee: kandrot → evaughan
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.