49428 - six nsBoxSizeListImpl objects leak on startup

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[Chris Waterson]

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.

Comment 1

[Bruce Mitchener]

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.

Comment 2

[Bruce Mitchener]

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.)

Comment 3

[Edward Kandrot]

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?

Comment 4

[Edward Kandrot]

Eric has checked in a fix for this.

Comment 5

[Eric Vaughan]

Fixed