Open Bug 382522 Opened 17 years ago Updated 16 years ago

Chatzilla causes DOMWindow leaks

Categories

(Other Applications :: ChatZilla, defect, P2)

Product:
Other Applications
Component:
ChatZilla
Platform:
x86
macOS
Type:
defect

Tracking

(Not tracked)

People

(Reporter: roc, Unassigned)

Details

(Keywords: memory-leak)

Attachments

(2 files)

leaklog on windows XP
15.91 KB, text/plain
Details
new leaklog
15.84 KB, text/plain
Details 
Start up a build, display FF start page, shut down: no DOMWindow leaks.

Start up a build, display FF start page, open Chatzilla (connecting to a few networks and channels automatically), shut down: leak some number of DOMWindows (18+).
How are you checking for leaks? Is this a debug build with the nice stats at the end, or are you using dbaron's leak monitor, or...? This would help in reproducing/debugging this...

Does it leak if you don't autoconnect anywhere? (try an otherwise clean profile, or empty the autoconnect list in the preferences)

Additionally, is this really Mac OS X only?
Frankly, I don't care about leaks on shutdown, but being able to see whatever it is you are using to make the assertion would clearly be beneficial.
Severity: normal → minor
I'm watching output from my debug build like
--DOMWINDOW == 150

I don't know if this is OS X only or not. The convention is to leave those fields set until we prove it happens on other platforms.

If I don't autoconnect anywhere, we leak 6 DOMWindows.

> Frankly, I don't care about leaks on shutdown

Well that's too bad, since DOMWindow leaks cause nsLayoutModule::Shutdown to not get fired, which causes my layout shutdown cleanup code to not run, which causes a crash on shutdown every time. Plus, we don't know for sure that these are only shutdown leaks.
Clearly nsLayoutModule and/or the crash needs fixing. I don't think it is relevant here.

If you can catch some/any leaks with e.g. David Baron's leak monitor extension, that would be significantly useful, since it gives some information that can be used to pinpoint objects and code that got caught up. I'm afrade that with only the DOMWINDOW debug lines, there isn't anything we can do.
I also can't reproduce any leak on my trunk Firefox build (20070527). The DOMWINDOW count happily reaches 0, whether I close ChatZilla before I quit Firefox, or let it get closed as part of the shutdown.
> Clearly nsLayoutModule and/or the crash needs fixing. I don't think it is
> relevant here.

We can patch things so that we don't crash, just leak more. That's not a very appealing way to work around your bugs.
OK, I downloaded a Mac nightly build, ran

NSPR_LOG_MODULES=DOMLeak:5,DocumentLeak:5,nsDocShellLeak:5  /Volumes/Minefield/Minefield.app/Contents/MacOS/firefox -P Test2 >& ~/tmp/leak-log

displayed start page, started Chatzilla, then shut down the browser.

Then ran

~/bin/leak-gauge.pl ~/tmp/leak-log

and got

Leaked outer window 203c2a00 at address 203c2a00.
Leaked inner window 20787380 (outer 203c2a00) at address 20787380.
 ... with URI "chrome://chatzilla/content/output-window.html".
Leaked inner window 1a88af30 (outer 1a817460) at address 1a88af30.
 ... with URI "about:blank".
Leaked outer window 1a817460 at address 1a817460.
Leaked outer window 1bf7d30 at address 1bf7d30.
Leaked inner window 1bf57e0 (outer 1bf7d30) at address 1bf57e0.
 ... with URI "about:blank".
Leaked document at address 1a4809d0.
 ... with URI "jar:file:///Volumes/Minefield/Minefield.app/Contents/MacOS/chrome/toolkit.jar!/content/global/platformHTMLBindings.xml".
 ... with URI "chrome://global/content/platformHTMLBindings.xml".
Leaked document at address 26c5400.
 ... with URI "jar:file:///Users/roc/Library/Application%20Support/Firefox/Profiles/vflhyf8x.Test2/extensions/%7B59c81df5-4b7a-477b-912d-4e0fdf64e5f2%7D/chrome/chatzilla.jar!/content/chatzilla/output-window.html".
 ... with URI "chrome://chatzilla/content/output-window.html".
Leaked document at address 246dc00.
Summary:
Leaked 6 out of 12 DOM Windows
Leaked 3 out of 42 documents
Leaked 0 out of 5 docshells

If I start the browser, open Chatzilla, close it, then shut down the browser I get the same results (6 windows leaked).

If I start the browser, open Chatzilla, close it, open Chatzilla, and close it again, I leak 10 windows:

Leaked inner window 1fa79250 (outer 1f1857c0) at address 1fa79250. ... with URI "about:blank".
Leaked outer window 1a8b6ac0 at address 1a8b6ac0.
Leaked inner window 1fa87390 (outer 1f1d9bd0) at address 1fa87390.
 ... with URI "chrome://chatzilla/content/output-window.html".
Leaked outer window 1ab45360 at address 1ab45360.
Leaked outer window 1f1857c0 at address 1f1857c0.
Leaked inner window 1a8ba930 (outer 1a8b6ac0) at address 1a8ba930.
 ... with URI "about:blank".
Leaked outer window 1bf7d10 at address 1bf7d10.
Leaked outer window 1f1d9bd0 at address 1f1d9bd0.
Leaked inner window 1b12bdb0 (outer 1ab45360) at address 1b12bdb0.
 ... with URI "chrome://chatzilla/content/output-window.html".
Leaked inner window 1bf57e0 (outer 1bf7d10) at address 1bf57e0.
 ... with URI "about:blank".
Leaked document at address 26caa00.
 ... with URI "jar:file:///Users/roc/Library/Application%20Support/Firefox/Profiles/vflhyf8x.Test2/extensions/%7B59c81df5-4b7a-477b-912d-4e0fdf64e5f2%7D/chrome/chatzilla.jar!/content/chatzilla/output-window.html".
 ... with URI "chrome://chatzilla/content/output-window.html".
Leaked document at address 23ff200.
Leaked document at address 2064c00.
Leaked document at address 2507000.
 ... with URI "jar:file:///Users/roc/Library/Application%20Support/Firefox/Profiles/vflhyf8x.Test2/extensions/%7B59c81df5-4b7a-477b-912d-4e0fdf64e5f2%7D/chrome/chatzilla.jar!/content/chatzilla/output-window.html".
 ... with URI "chrome://chatzilla/content/output-window.html".
Leaked document at address 1a480b80.
 ... with URI "jar:file:///Volumes/Minefield/Minefield.app/Contents/MacOS/chrome/toolkit.jar!/content/global/platformHTMLBindings.xml".
 ... with URI "chrome://global/content/platformHTMLBindings.xml".
Summary:
Leaked 10 out of 17 DOM Windows
Leaked 5 out of 46 documents
Leaked 0 out of 7 docshells

So this is clearly not just a shutdown leak. You're probably leaking every time the user opens and closes the window.
On a Linux build, CVS checkout -D 2007-05-31 10:07 -0700, I don't get any leaks:
Summary:
Leaked 0 out of 7 DOM Windows
Leaked 0 out of 23 documents
Leaked 0 out of 3 docshells

(Using http://lxr.mozilla.org/mozilla/source/tools/footprint/leak-gauge.html following the in-page directions)

Both debug and optimized builds.  CZ-on-XULRunner.

Using the same sources, but building Firefox and CZ as an extension instead:

Summary:
Leaked 0 out of 12 DOM Windows
Leaked 0 out of 42 documents
Leaked 0 out of 5 docshells

(and same, without Chatzilla being run, but still installed:)
Summary:
Leaked 0 out of 7 DOM Windows
Leaked 0 out of 38 documents
Leaked 0 out of 3 docshells

Note that my tests just involve opening the Chatzilla window (and in the Firefox case, starting from the Firefox window) and closing everything.  I did not attempt to attach to any servers or join any channels.

This might end up as being Mac specific; I do not have a Mac to test with.

I don't pretend to know anything, I just figured more data might help.
Roc, can you still repro this?
Yes. I leak 8 DOMWindows after starting up, opening Chatzilla (but not connecting), and then quitting.

This could easily be Mac only.
OK, so on Mac XULRunner, I get up to ++DOMWINDOW == 7, and then down to --DOMWINDOW == 4. The fact that "we" leak more when we run on Firefox, and the fact that this is Mac OS only makes me really really suspicious. I don't have the time to look into this right now, though :-(. Maybe in 2 months or so. Again, I very much suspect that this is a core bug, mostly because it doesn't happen on anything but Mac (and we don't really do anything particularly special on mac, as far as I know...)

Finally I find it particularly odd that if I use cmd+Q to quit ChatZilla (which on Mac will invoke the builtin quit procedure and bypasses part of ChatZilla's code) will (down here, anyway) leak 7 domwindows (then I don't get any --DOMWINDOW lines), while using /quit in the client's input field leaks only 4 (as described above).

PS: you will need my patch from bug 372453 to make /quit actually *work* on Mac OS X. Blame cocoa.
Attached file leaklog on windows XP — 
leaklog on Windows XP

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082005 Minefield/3.0a8pre ID:2007082005

extensions:
ChatZilla 0.9.78.1
DOM Inspector 1.9a8pre
Leak Monitor 0.3.6 [DISABLED]
Nightly Tester Tools 1.3b3

Summary

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082005 Minefield/3.0a8pre ID:2007082005

Session ended dinsdag 21 augustus 2007 0:56:01

Leaked 5 out of 17 DOM windows
Leaked 0 out of 48 documents
Leaked 0 out of 7 docshells

Details

Leaked inner window 18dbb60 (outer 0) at address 18dbb60.
Leaked outer window 24bd250 at address 24bd250.
 ... with URI "about:blank".
Leaked inner window 33cd150 (outer 0) at address 33cd150.
Leaked outer window 34000d0 at address 34000d0.
 ... with URI "about:blank".
Leaked outer window 36513b8 at address 36513b8.
 ... with URI "chrome://chatzilla/content/output-window.html".
steps to repeat

- open Minefield with default homepage <http://www.mozilla.org/projects/minefield/>
- open chatzilla
- log in automatically to irc://moznet/ and join automatically to #developers
- quit chatzilla by clicking the close button top-right
- quit Minefield the same way
It would be much better if we had steps to reproduce that did not include "connect automatically to..." - does a leak occur for such situations also?
See comment #3:
> If I don't autoconnect anywhere, we leak 6 DOMWindows.
(In reply to comment #16)
> See comment #3:
> > If I don't autoconnect anywhere, we leak 6 DOMWindows.
> 

Right, but that doesn't have a leak log, or any other info (I'm sorry, I should have mentioned that immediately, my previous comment was badly worded). Heck, in comment #11 you said you leak 8 DOMWindows when you don't connect - so all in all this is still fuzzy. :-(

I'll try to debug this myself in a bit, but I'm not the best person to be doing this, what with me not knowing a whole lot about leaks...
I can't actually reproduce this at all on Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007092600 Minefield/3.0a9pre (local debug build)

Steps I'm using:

1. Create a new profile, start browser.
2. Open https://addons.mozilla.org/addon/16
3. Install ChatZilla 0.9.78.1
4. Restart from the addons manager, quit the resulting browser.
5. Turn on XPCOM_MEM_LEAK_LOG in XCode
6. Run MinefieldDebug.app/Contents/MacOS/firefox-bin in XCode. The only page opening is the minefield start page.
7. Focus the window, click "Tools", click "ChatZilla". Wait for it to have opened completely and given you the welcome messages and such.
8. Use cmd+Q to exit the app.

The leak table then looks like http://pastebin.mozilla.org/206938

Optionally, 7b.: close the ChatZilla window (per comments by Jo Hermans). This didn't make any difference to the leak table.

roc, I hate to ask you again, but can you still repro on current trunk, using the steps above? And/or can you point out what I'm doing 'wrong' that causes me not to be able to repro, and amend the steps in this comment? Thanks a lot!
Attached file new leaklog — 
Gijs, I have been using the following settings for the logging. I was looking for DOM leaks and docshell leaks, not xpcom leaks :

set NSPR_LOG_MODULES=DOMLeak:5,DocumentLeak:5,nsDocShellLeak:5

I tested again today (Gecko/2007092605 Minefield/3.0a9pre), and I still leaked with the testcase in comment 13. I tried 4 times, and I always got a leak. Sometimes I leaked 5 DOWM windows (as in comment 13), sometimes only 2.

Then I tried removing the the automatic channel-join. I still leaked 2 DOM windows.

Then I removed the automatic network login, and the leak disappeared.

Then I logged in the network manually (using the command line) - still no leak.

Then I enabled again the automatic network login (not the channel-join), and I got the leak again (2 DOM windows) ! I attach the login with this report.

To be sure that this is no dream, I repeated everything 4 times. Every time again, I leaked 2 DOM windows when automatical network-login was used. But I didn't leak anything when no network was joined (Chatzilla just showed the blue rectangle with the network selection below), or when I joined the moznet manually (by clicking on the network name). The only leak happened when I allowed Chatzilla to open moznet automatically. No channel was joined.

Note that I closed the Chatzilla manually every time, and I always got the default warning dialog.
Is this reproducible using Leak Monitor? If so, is it possible this is just bug 400156?
I could certainly get nothing to show up in Leak Monitor when I tried to reproduce this.
So from comment #19 it seems we're leaking the *client* tab (which we hide when you auto-connect). I have no idea *why* though. My brain claims I checked in a mini null out thing in a failed attempt to fix bug 400156 ages ago (without a bug, with r from Silver on IRC, but bonsai seems to say I'm totally making that up). :\

Regardless, this is still reproducible I guess? Jo?
(In reply to comment #22)
> Regardless, this is still reproducible I guess? Jo?

Yes, it still is.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008010904 Minefield/3.0b3pre

sounds like the test case in 
https://bugzilla.mozilla.org/show_bug.cgi?id=412207#c8
and leak log in
https://bugzilla.mozilla.org/show_bug.cgi?id=412207#c7
may apply better to this bug.
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Flags: tracking1.9+
Version: unspecified → Trunk
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: