As mentioned in a newsgroup posting to n.p.m.performance -- There is a problem : using Mozilla to display a HTML screen every 3 second leaks about 2,3 Mo an hour (We just call nsIWebNavigation::LoadURI with the same URI). This make it not possible for this application to turn continuously. -- the file is attached

a run through tracemalloc (linux trunk) shows the following: operator new(unsigned) nsCSSOMFactory::CreateDOMCSSAttributeDeclaration(nsIHTMLContent*, nsDOMCSSDeclaration**) nsGenericHTMLElement::GetStyle(nsIDOMCSSStyleDeclaration**) nsGenericHTMLElementTearoff::GetStyle(nsIDOMCSSStyleDeclaration**) but they're pretty small leaks - certainly nothing as big as reported - and I can't see anything from NS_CreateHTMLElement... so I'm not sure if this is the same leak as reported.

If the original reporter could run purify over a trunk mozilla, that would be useful...

This test is with debug binairies of Mozilla. New leaks are cleared each time the document is loaded.

To what component should this one be best assigned to?

Assigning to DOM-Other for now, reassign as needed. Also, I notice "lang=fr", could this be significant?

I did a spacetrace analysis on this page. Saw memory growth of 483,526 bytes after loading the page 3 times within approx 15min time frame. (data focus is narrowed down to the allocations when test page loads, and ends w/ loading a blank page) There are total of 120 leaks according to spacetrace data, which mounts up to total of 13,176 byte size. The rest (or the majority) of allocation growth are just bloat, or allocation we hold on during the lifetime of the app. Attaching top-level leak stacks. (sorry links won't work externally, if you need details on a specific stack, email me the stack # for more data)

Comment on attachment 127484 [details] [diff] [review] fix DOM Style leak Excellent.

Taking.

This uses a member instead of a pointer, and goes back to QI macros.

Comment on attachment 127491 [details] [diff] [review] fix DOM Style leak >Index: nsDOMCSSDeclaration.cpp >-CSS2PropertiesTearoff::CSS2PropertiesTearoff(nsISupports *aOuter) >+CSS2PropertiesTearoff::CSS2PropertiesTearoff(nsIDOMCSSStyleDeclaration *aOuter) > { >- NS_INIT_AGGREGATED(aOuter); >+ mOuter = aOuter; > } How about: CSS2PropertiesTearoff::CSS2PropertiesTearoff(nsIDOMCSSStyleDeclaration *aOuter) : mOuter(aOuter) { NS_ASSERTION(mOuter, "Must have CSSDeclaration to forward to"); } ? r+sr=me with that.

Fix checked in to trunk, 2003-07-11 13:44 -0700. Is that the only problem covered by this bug, or is this fixed?

Comment on attachment 127502 [details] [diff] [review] fix DOM Style leak Requesting 1.4.x approval, because I think this is a rather serious leak, and the fix is pretty simple...

The Purify output shows leaks from NS_CreateHTMLElement and NS_GetModule....

Comment on attachment 127483 [details] spacetrace leak data (call stacks) cathleen's spacetrace log doesn't show the reported leak (it shows the one dbaron's already fixed). jmour: can you generate some actual Purify callstacks for us? what you've provided isn't enough to see where the problem is, and no one else has been able to reproduce the leak so far...

Comment on attachment 127502 [details] [diff] [review] fix DOM Style leak a=mkaply

please add fixed1.4.1 keyword when this is checked in.

Checked in to 1.4 branch.

Due to lack of response to comment 17, marking the bug fixed as well. Please file a new bug for information about any other leaks.