Starting sometime between 2000-08-02 23:26 and 2000-08-03 00:18, we leak an nsXBLEventHandler every time the browser is run. The checkins during that perioud were mostly ben's UI changes: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2000-08-02+23%3A16&maxdate=2000-08-03+00%3A28&cvsroot=%2Fcvsroot The leaked object is the first one created (well, really the first one whose |AddRef| method is called). It is |AddRef|d once and never |Release|d. The |AddRef| is here: <nsXBLEventHandler> 0x08688DE8 1 AddRef 1 nsXBLEventHandler::AddRef(void)+0x0000006F NS_NewXBLEventHandler(nsIContent *, nsIContent *, nsString const &, nsXBLEventHandler **)+0x00000064 nsXBLBinding::InstallEventHandlers(nsIContent *, nsIXBLBinding **)+0x0000069D nsXBLService::LoadBindings(nsIContent *, nsString const &, int, nsIXBLBinding **)+0x000009B8 nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell *, nsIPresContext *, nsFrameConstructorState &, nsIContent *, nsIFrame *, nsIAtom *, int, nsIStyleContext *, nsFrameItems &, int)+0x0000014F nsCSSFrameConstructor::ConstructFrame(nsIPresShell *, nsIPresContext *, nsFrameConstructorState &, nsIContent *, nsIFrame *, nsFrameItems &)+0x00000202 nsCSSFrameConstructor::ProcessChildren(nsIPresShell *, nsIPresContext *, nsFrameConstructorState &, nsIContent *, nsIFrame *, int, nsFrameItems &, int, nsTableCreator *)+0x000001F7 nsCSSFrameConstructor::ConstructDocElementFrame(nsIPresShell *, nsIPresContext *, nsFrameConstructorState &, nsIContent *, nsIFrame *, nsIStyleContext *, nsIFrame *&)+0x00000859 nsCSSFrameConstructor::ContentInserted(nsIPresContext *, nsIContent *, nsIContent *, int, nsILayoutHistoryState *)+0x00000A56 StyleSetImpl::ContentInserted(nsIPresContext *, nsIContent *, nsIContent *, int)+0x00000037 PresShell::InitialReflow(int, int)+0x00000416 nsXULDocument::StartLayout(void)+0x000006D6 nsXULDocument::ResumeWalk(void)+0x000015D9 nsXULDocument::EndLoad(void)+0x0000065D XULContentSinkImpl::DidBuildModel(int)+0x0000008E CWellFormedDTD::DidBuildModel(unsigned int, int, nsIParser *, nsIContentSink *)+0x0000005B nsParser::DidBuildModel(unsigned int)+0x00000076 nsParser::ResumeParse(int, int)+0x00000236 nsParser::OnStopRequest(nsIChannel *, nsISupports *, unsigned int, unsigned short const *)+0x000000E3 nsResChannel::EndRequest(unsigned int, unsigned short const *)+0x0000005A nsResChannel::OnStopRequest(nsIChannel *, nsISupports *, unsigned int, unsigned short const *)+0x00000100 nsFileChannel::OnStopRequest(nsIChannel *, nsISupports *, unsigned int, unsigned short const *)+0x00000081 nsOnStopRequestEvent::HandleEvent(void)+0x00000125 nsStreamListenerEvent::HandlePLEvent(PLEvent *)+0x0000005F PL_HandleEvent+0x00000056 PL_ProcessPendingEvents+0x00000110 nsEventQueueImpl::ProcessPendingEvents(void)+0x00000071 nsAppShell::SetDispatchListener(nsDispatchListener *)+0x0000003C keysym2ucs+0x0000015F g_io_add_watch+0x000000AA g_get_current_time+0x00000136 g_get_current_time+0x00000701 g_main_run+0x00000081 gtk_main+0x000000B9 nsAppShell::Run(void)+0x00000052 nsAppShellService::Run(void)+0x0000003C UNKNOWN 0x08053305 UNKNOWN 0x080539D8 __libc_start_main+0x000000FF

One per launch? How bad is that?

One per whatever we do in the bloat tests. I don't know what it is or how often it happens in normal use.

I see this regularly when running ...

12 bytes or so per window, ->future. Sorry Bruce, but dbaron will probably fix this anyway!

not this one...

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

I futured this bug when it was 12 bytes per window. Current TBox leaky tests seem to show it much worse recently. What is the leak rate now?

asking for rtm, this is a root leak that is causing other leaks (thousands of bytes).

so if this object is leaked once per window, and we've attatched 8k more bytes to this object, that yeilds ~8k per window now. It sounds like Hyatt has a fix in mind, I say we take it to remove the possibility of it becoming 100k per window down the line.

adding self to cc list - I'm wondering if fixing this will clean up some thread pane leaks after scrolling, since that does involve event handlers.

Cool, this does seem to fix the leak of nsXULDocuments when you scroll the thread pane with the thumb (which caused all the nsMsgHdrs to get leaked, etc). So, if this was what fixed this leak (and not some earlier checkin), at least for mail/news, this leak was more like megabytes then k's. Thanks for fixing this!

rtm+ need info, get reviewer and super-approver to add their a=/r=, then remove 'need info'

This was fixed when I landed 53417 on the branch. I wasn't going to land a leaky 53417 patch on the branch, nor was I going to deliberately unwind my XBL files back to the leaky state just so that I could land 53417. So this fix just went in on the branch. Marking fixed.

dbaron: is this leak fixed (I believe it is).

Not in tinderbox leak stats -> VERIFIED, removing vtrunk kw.