40291 - nsXULDocument::gRefCnt holding reference to nsXULPrototypeCache causing shutdown memory leak

Status: VERIFIED DUPLICATE of bug 24645

(Core Graveyard :: RDF, defect, P3)

Description

[Yixiong Zou]

if nsXULDocument::gRefCnt!=0 during shutdown, the nsXULPrototypeCache will not 
be freed. 

System:
RedHat linux 6.0, mozilla build on May 18. 

How to Reproduce:
1. open up mozilla, load www.mozilla.org
2. click on the URL location bar, then hit enter, this will re-load the page
3. exit mozilla

If XPCOM_MEM_lEAK_LOG is set, we should be able to see that nsXULPrototypeCache 
is in the leaked list. The reason is that when the page is re-loaded, 
nsXULDocument::Init is called again, this incremented nsXULDocument::gRefCnt to 
2, and thus, during the dtor of nsXULDocument, the gXULCache it holding is not 
freed.

Comment 1

[Chris Waterson]

We should also be leaking an nsXULDocument, in this case, right?

Comment 2

[Yixiong Zou]

the dtor of nsXULDocument is called though. only because --gRefCnt!=0, so the 
gXULCache is not freed, so does other stuff. 

Comment 3

[Yixiong Zou]

waterson, you are right. there is a leak for nsXULDocument also. 

Comment 4

[Chris Waterson]

There are several nsXULDocument objects that are created to bring up the main 
browser window. Just because you hit the dtor for one of them doesn't mean all 
of them got destroyed! :-)

What does the bloat log report in this case?

Comment 5

[Yixiong Zou]

nsXULDocument shows up in Bloat log. 3 object created, 2 of them remained after 
shutdown. 

Comment 6

[Yixiong Zou]

this bug appears to have a dependency on bug#27739. The 2 nsXULDocument that 
are leaked are the 2 XUL files that contains the key binding. If we start the 
mozilla without profile manager, using option -P, and release the 
nsXULKeyListenerImpl::mKeyBindingTable, then the nsXULDocument would be freed. 

Could someone verify this for me?

Comment 7

[Chris Waterson]

This will be fixed when hyatt checks in 24645. It's not really a "dup" of 24645
(or 27739), but I'm going to mark it that way. It's a symptom of the hackery
that was put in to circumvent 27739 from causing text fields to bust.

*** This bug has been marked as a duplicate of 24645 ***

Comment 8

[John Morrison]

verified dup (as I was passing by...)