381897 - Increase in Rlk due to check-in for bug 368774

Status: VERIFIED FIXED

(Core :: XPCOM, defect)

Description

[Adam Guthrie]

Check-ins: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1180015320&maxdate=1180016219

5360	MOZ_CO_DATE=2007:05:24:07:02
6240	MOZ_CO_DATE=2007:05:24:07:17

--NEW-LEAKS-----------------------------------leaks-
nsXBLInsertionPointEntry                        880          -
TOTAL                                           880

Comment 1

[Peter Van der Beken [:peterv]]

This seems to be a problem with the nsXBLInsertionPointEntry nsFixedSizeAllocator being released before we release all the objects in it.

Comment 2

[Robert Kaiser]

As I suspected over in bug 368774, nye SeaMonkey has the same problem:

--NEW-LEAKS-----------------------------------leaks
nsXBLInsertionPointEntry                        720 


So at least we have consistency across tinderboxen (and even toolkit vs. xpfe) :)

Comment 3

[Peter Van der Beken [:peterv]]

The problem is that the nsFixedSizeAllocator is created/destroyed by the nsXBLPrototypeBindings. That used to be ok, because as long as there were nsXBLPrototypeBindings alive we kept the nsFixedSizeAllocator alive and nsXBLInsertionPointEntrys were only used in nsXBLPrototypeBinding. Now the nsXBLInsertionPointEntrys can become white and when we try to unlink them we root them by AddRef'ing them. At the end of unlinking the last nsXBLPrototypeBinding has been released, destroying the nsFixedSizeAllocator. We then release the white nsXBLInsertionPointEntrys, but they're garbage and their refcount is bogus.

Comment 4

[Adam Guthrie]

Hrm... so the patch peterv just landed fixed the nsXBLInsertionPointEntry leak, but introduced some other leaks:

--NEW-LEAKS-----------------------------------leaks------leaks%
XPCWrappedNativeProto                           700       4.17%
XPCWrappedNative                               1568       3.70%
TOTAL                                          2268
--FIXED-LEAKS---------------------------------leaks------leaks%
nsXBLInsertionPointEntry                          0    -100.00%
TOTAL                                             0

Comment 5

[Robert Kaiser]

Interestingly, those new leaks do not show up in nye's last run, the nsXBLInsertionPointEntry leaks are fixed there as well though.

So, either that's something we only leak in toolkit and not xpfe (which could tell something about where/why we leak those), or we leak them in Firefox code and not in SeaMonkey code - or we don't always leak them.

Comment 6

[Peter Van der Beken [:peterv]]

Attachment: Patch that was checked in

Here's what I checked in to fix the leak regression and the orange on tinderbox.

(In reply to comment #4)
> Hrm... so the patch peterv just landed fixed the nsXBLInsertionPointEntry leak,
> but introduced some other leaks:

No, it didn't. Those are leaks that already happened occasionally before I landed.

Comment 7

[Adam Guthrie]

Ah, indeed. ->VERIFIED