Closed Bug 102655 Opened 23 years ago Closed 21 years ago

[MLK][Windows only]XUL prototype cache shuts down after XPConnect

Categories

(Core :: XUL, defect, P4)

Product:
Core
Component:
XUL
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 199465
Milestone:
Future

People

(Reporter: risarisa, Assigned: dbaron)

References

Details

(Keywords: memory-leak) 

js/src/jsapi.cline 1411
Reporter, could you be a little more specific?  The line you cite is in a
function that's supposed to allocate memory and return a pointer to the newly
allocated memory.  There seems to be nothing wrong with that function....  What
leaks do you mean exactly?
mozilla start and immediately finish.
over 2000 count of memory leak generated.

Boris, you are right.
But pointer not controled.
> mozilla start and immediately finish.
> over 2000 count of memory leak generated.

I presume this is from some tool like Purify?

> But pointer not controled.

What do you mean?

If you could attach some clear evidence of the leaks (whatever you may have) that 
would be very helpful....

The number of times of memory leak decreases in the latest version.
But, memory leak (with JS_malloc()) still happens about 600 times.
One of those happens by the next call.

js/src/jsapi.c 1411 <- JS_malloc()
js/src/jsscope.c 509
js/src/jsobj.c 1976
js/src/jsfun.c 1954
js/src/jsapi.c 2793
js/src/jsapi.c 2775
js/src/jsapi.c 1840
js/src/jsobj.c 1522
js/src/jsapi.c 1068
js/src/jsapi.c 1337
dom/base/src/nsDOMClassInfo.cpp 2878
js/src/xpconnect/src/xpcwrappednativejsops.cpp 892
js/src/jsobj.c 2149
js/src/jsobj.c 2359
js/src/xpconnect/src/xpcwrappednativescope.cpp 177
js/src/xpconnect/src/nsXPConnect.cpp 455
dom/src/base/nsJSEnvironment.cpp 1115
dom/src/base/nsJSEnvironment.cpp 1650
dom/src/build/nsDOMFactory.cpp 121


confirming based on that info.
Status: UNCONFIRMED → NEW
Ever confirmed: true
> mozilla start and immediately finish.

risarisa@milk.freemail.ne.jp: are you saying that Mozilla crashes
                              every time you try to start it up?
Assignee: rogerl → khanson
risarisa@milk.freemail.ne.jp: what build date of Mozilla are you using?
                              Is it a recent build? 
>are you saying that Mozilla crashes every time you try to start it up?

No.Mozilla not crashes, but have many many memory leaks.
This leak increases when new URL that a window is made is opened.

> what build date of Mozilla are you using?$B!!(BIs it a recent build? 

Yes.
I use CVS.




cc'ing Brendan and jband : is there a well-defined problem suggested by
this report, or do we still need more info from risarisa@milk.freemail.ne.jp?
I don't think this bug is valid as stated.  The leaks that entrain JS objects
typically are due to stuck XPCOM refcounts in docshell or other native (C++)
code, possibly due to cycles (maybe even JS GC root <=> refcount cycles).  I'm
thinking this needs to be marked INVALID, but maybe we can get useful stacks and
blame the bug on the right code?

/be
Could you try:

set XPCOM_MEM_LEAK_LOG=leak.log
mozilla

and then attach the leak.log file?
risarisa@milk.freemail.ne.jp: have you had a chance to try dbaron's 
suggestion in Comment 11? If we don't recieve more information, we'll
have to close this bug as invalid, as indicated in Comment 10. Thanks - 
== BloatView: ALL (cumulative) LEAK STATISTICS

     |<----------------Class--------------->|<-----Bytes------>|<---------------
-Objects---------------->|<--------------References-------------->|
                                              Per-Inst   Leaked    Total      
Rem      Mean       StdDev     Total      Rem      Mean       StdDev
   0 TOTAL                                          19     1956   617731      
116 ( 2598.44 +/-  1547.20)   866765       16 ( 1179.03 +/-  1693.60)
 101 XPCNativeScriptableShared                      76       76      231        
1 (   17.58 +/-     6.19)        0        0 (    0.00 +/-     0.00)
 103 XPCWrappedNative                               52       52      964        
1 (  320.70 +/-   159.56)    22013        1 (  497.53 +/-   201.51)
 137 nsBaseDragService                              52       52        1        
1 (    1.00 +/-     0.00)       29        4 (   11.24 +/-     5.66)
 183 nsCaseConversionImp2                           12       12        1        
1 (    1.00 +/-     0.00)        9        2 (    3.88 +/-     1.93)
 299 nsHashtable                                    44       44      795        
1 (  365.99 +/-   211.71)        0        0 (    0.00 +/-     0.00)
 423 nsStr                                          16     1040   386531       
65 ( 2934.60 +/-  1053.16)        0        0 (    0.00 +/-     0.00)
 432 nsSupportsArray                                56       56     1577        
1 (  464.59 +/-   244.77)    16567        1 (  480.95 +/-   260.68)
 437 nsSystemPrincipal                              52       52        1        
1 (    1.00 +/-     0.00)    19354        0 (   25.78 +/-     8.97)
 459 nsTimer                                        44      176       36        
4 (    9.47 +/-     3.88)      155        4 (   17.64 +/-     7.25)
 460 nsTimerManager                                 24       24        1        
1 (    1.00 +/-     0.00)        8        2 (    2.79 +/-     1.19)
 473 nsVoidArray                                     8      296    11676       
37 ( 2502.90 +/-  1150.81)        0        0 (    0.00 +/-     0.00)
 506 nsXPCComponents                                48       48       10        
1 (    2.95 +/-     1.43)      120        1 (   11.43 +/-     5.01)
 525 nsXULPDGlobalObject                            28       28       22        
1 (   11.26 +/-     6.28)      225        1 (   24.90 +/-    15.49)

Sorry,"freemail.ne.jp" is often lost mail. So I dont got the mail of #11.
Recently,CVS version is unstable, and I could not often compile mozilla.
So, I can not report correctly.
You should probably focus on the nsXULPDGlobalObject leak.  I think we always
leak that XPCWrappedNative, and it's related to the XPCComponents leak, but I
don't remember if that entrains some JS stuff too.
This bug should go to someone motivated and able to debug it, and (ideally) to
someone responsible for XUL leaks.  I don't think it's khanson's baby.  I'm
cc'ing shaver and waterson, but they're pretty overloaded.

LisaLisa7, are you willing to take this bug and investigate further?  dbaron
says you may find the refcnt balancer tutorial document that he wrote, located
at http://www.mozilla.org/performance/leak-tutorial.html, to be helpful.

/be
I agree this is probably not my baby.  Any takers?  Moving to 9.7
Brendan,

Is this a 1.0 bug or can we move it beyond especially since there are no takers?
I'm going to give dbaron a chance to take it -- he loves leaks!  But he should
not be the only one giving them love.  Cc'ing cathleen and dp.

/be
Assignee: khanson → dbaron
I did have a chance to look into this bug briefly when I was debugging leaks on
Windows.  I believe it was a problem related to XPConnect (and JS component
loader?) shutdown ordering, although I could be wrong.  I know that was the
cause of the leaked nsXPCComponents and its wrapper (as it is on Linux), but the
leak of the nsXULPDGlobalObject was Windows-only, and perhaps related to the
order the components are shut down.  Although I could be confusing this with the
JS-component leak visible in mail compose, and that was already a week ago so my
memory isn't clear anymore...
Oh, I remember.  It had to do with the difference in shutdown order between the
XPConnect component and the content component, since the content module
destructor calls nsXULElement::ReleaseGlobals(), which releases the XBL service,
which, when destroyed, releases the XUL prototype cache.  (I really wonder why
the XBL Service maintains a gRefCnt (meaning gInstanceCount), since it's a
service and that should always be 1.)
So the solution may be to ensure that the things that will hold on to the XUL
prototype cache are released in the content module's shutdown observer rather
than it its module destructor.  That requires some rather messy fiddling with
shutdown order.

I'll leave this bug to cover the nsXULPDGlobalObject leak rather than the
others, since I'm reasonably sure it's the only bug on that leak whereas I
*think* there's already a bug on the nsXPCComponents leak (which was an internal
XPConnect issue).  And I suspect it's more likely the nsXULPDGlobalObject leak
that's responsible for most of the jsapi.c leaks.

So, any takers for fiddling with shutdown, since I don't have a Windows
development box anymore?  (Would the cause for the order difference in shutdown
be a difference in component startup order?)
Summary: [MLK]too many memory leak in jsapi.c → [MLK][Windows only]XUL prototype cache shuts down after XPConnect
*** Bug 110702 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Priority: -- → P4
Target Milestone: --- → Future
i'm actually playing with stuff near this, but i'm going to claim that it isn't
a jsengine bug.
Component: JavaScript Engine → XP Toolkit/Widgets: XUL
Setting default QA -
QA Contact: pschwartau → shrir
I assume you meant bug 199465 :-)

IMO yes, it is. While the shutdown of the XUL prototype cache hasn't been
changed, in bug 199465 I made the DOM code, which performes a final GC from its
shutdown nitifcation callback, flush the XUL prototype cache before starting the
GC, this makes the XUL prototype cache unroot everything it has rooted, and thus
the leaks caused by those roots are fixed.

Duping.

*** This bug has been marked as a duplicate of 199465 ***
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.