Patrick C. Beard Reporter
	Description • 25 years ago

I don't understand this leak, but it originates from the annotated stack crawl
that I am attaching. Take a look. One interesting thing is that the object refers
to itself in its mRoot data member.

	John Bandhauer Assignee
	Comment 2 • 25 years ago

The JS code handling the event is in turn calling some native object.
The native object has returned some interface pointer and XPConnect
has built a wrapper around that interface pointer. For whatever reason in the JS
code JSObject of that wrapper is not be let go of. Either GC is not happening or
there is some rooted object in that context holding a reference to the wrapper.

It is very unlikely that this is an xpconnect bug per se.

The bit about the mRoot pointing to the self-same wrapper is not unusual.
XPConnect builds a chain of wrappers around a 'logical' xpcom object. This is
singly linked chain, but each link has a pointer back the the root (or head) of
the chain. The mRoot always represents the 'nsISupports' interface pointer of
the wrapped logical object. If the logical object returns the same interface
pointer for the requested interface and the nsISupports interface then xpconnect
can use the same wrapper to represent both the requested interface and the
nsISupports (root) interface.

	Jean-Francois Ducarroz
	Comment 3 • 25 years ago

nsMsgCompose leak beacause of this problem. If you start apprunner and then open a msg compose window (menu
file/new message) and then close manually the window (click in closebox), the nsMsgCompose object hold by the JS
global msgCompose (MsgComposeCommands.js) is not released because its wrapper in not released too. But, then if
you open another compose window and close it, the wrapper is correctly released as well the nsMsgCompose object.

	John Bandhauer Assignee
	Comment 4 • 25 years ago

*** Bug 28542 has been marked as a duplicate of this bug. ***

	John Bandhauer Assignee
	Comment 5 • 25 years ago

NOTE: the dup of this bug  - http://bugzilla.mozilla.org/show_bug.cgi?id=28542 
has some nice refcount balancer output.

	John Bandhauer Assignee
	Comment 6 • 25 years ago

The wrappednatives leaking are nsIXPCComponents objects that are bound to global 
'window' objects. These leak because nsJSContexts leak. They leak because 
XULPrototyeScript stuff has a cycle in JavaScript's heap because of 'misuse' of 
JS_AddNamedRoot. http://bugzilla.mozilla.org/show_bug.cgi?id=28570 is the key.

	John Bandhauer Assignee
	Comment 7 • 25 years ago

I believe this is fixed