six nsBoxSizeListImpl objects leak on startup

RESOLVED FIXED

Status

()

P3
normal
RESOLVED FIXED
18 years ago
10 years ago

People

(Reporter: waterson, Assigned: eric)

Tracking

({memory-leak})

Trunk
memory-leak
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
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.
(Reporter)

Updated

18 years ago
Keywords: mlk

Comment 1

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
Eric has checked in a fix for this.
Assignee: kandrot → evaughan
(Assignee)

Comment 5

18 years ago
Fixed
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Updated

10 years ago
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.