224661 - (chatzillamemoryhog) OS/2 - massive memory consumption by Chatzilla

Status: RESOLVED INVALID

(Other Applications :: ChatZilla, defect)

Description

[Felix Miata]

Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.6a) Gecko/20031101

I started 0.9.44 in 1.4.1 in Fedora Core 0.95, and 0.9.45 in the above OS/2
trunk build. In both, autostart was set to warpzilla, mozilla, mozillazine,
chatzilla & evangelism on moznet, and to fedora on freenode. Scrollback buffers
set to defaults in both. Motif set to default with faces in both.

Loading resulted in the following consumption:
Fedora: 30452K
OS/2: 37,752,832 (~20% more)

Doing /testdisplay 20 times resulted in the following added consumption:
Fedora: 4964K
OS/2: 6,477,472 (~30% more)

Running each for 8 hours (without opening browser or mailnews the whole time)
and then closing resulted in the following increase in free RAM:
Fedora: 45032K
OS/2: 136,126,464 (~200% more)

Last week on OS/2 I did 12 hours of 0.9.46 only on 1.5 final, using 5 channels
on moznet, and motif default. Free RAM increase on shutdown was about 89.5M.

Yesterday on same OS/2 build as today's 8 hour test, I started 5 channels on
Moznet and the browser (15 or so tabs), and opened and closed mailnews several
times. After 21 hours uptime, free RAM was down to 500K. Shutting Moz down
resulted in a 201,293,824 byte increase in free RAM (no change in swapper since
boot).

Using 1.4.1 OS/2 builds, I normally could run browser, mailnews, and CZ for 5
days or more without exhausting free RAM or touching the swapper. Most I ever
recorded shutting down 1.4.1 was about 173.4M, and more typical was in the
130M-150M range, and all with the scrollback buffers set to ~double the
defaults. Before using any gcc OS/2 build, I never exhausted free RAM in less
than one day.

Currently, 1.6a browser (6 tabs) & 0.9.45 CZ (5 channels, 1 server) are open ~80
minutes, consuming about 60M.

Comment 1

[Robert Ginda]

One way to test this outside of chatzilla is to save the contents a channels as
.html, and then load it in mozilla in multiple tabs.  From the desired tab,
execute the following commands:

/eval f = fopen("INSERT NATIVE PATH HERE", ">")
/eval f.write(this.messages.ownerDocument.body.innerHTML)
/eval f.close()

Replace where it says "INSERT NATIVE PATH HERE" with a native path such as
"/home/rginda/log.html".

You may have to hand hack the .html file to insert the css reference.  See the
log I made using this method at
http://www.hacksrus.com/~ginda/chatzilla/log.html.  Of course, you want to make
a log much larger than this one.

Comment 2

[Felix Miata]

Your sample gives no clue what css reference to use.

Comment 3

[Felix Miata]

Attachment: 30567 byte #warpzilla 180 lines

Comment 4

[Felix Miata]

Attachment: 59370 byte #evangelism 311 lines

Comment 5

[Felix Miata]

Attachment: 73304 byte #chatzilla 181 lines

Comment 6

[Felix Miata]

Attachment: 351547 byte #mozillazine 684 lines (one <tr> per line)

darn that size limit - gotta download the big ones and unzip to load

Comment 7

[Felix Miata]

Attachment: 357109 byte #mozilla 208 lines (long line mostly unbroken)

These were collected according to comment 1. Here's the result of loading them
in in 2003110308 OS/2 trunk browser:
***
193.9M free before startup browser
166.4M free after startup browser
159.8M after load ircchatzilla.html
158.8M after load ircevangelism.html in a new tab
152.8M after load ircmozilla.html in a new tab
150.07M after load ircmozillazine.html in a new tab
149.99M after load ircwarpzilla.html in a new tab
193.3M free after shutdown browser
***
193.33M free before startup browser
166.15M free after startup browser
160.50M after load ircwarpzilla.html
159.26M after load ircevangelism.html in a new tab
158.06M after load ircchatzilla.html in a new tab
153.79M after load ircmozillazine.html in same tab
150.18M after load ircmozilla.html in a new tab
193.34M free after shutdown browser
***
193.34M free before startup browser
166.15M free after startup browser
160.69M after load ircwarpzilla.html
159.40M after load ircevangelism.html in a new tab
158.09M after load ircchatzilla.html in a new tab
152.86M after load ircmozillazine.html in a new tab
149.05M after load ircmozilla.html in a new tab
193.35M free after shutdown browser
 44.30M net consumption (one each of all five)
***
193.35M free before startup browser
166.22M free after startup browser
160.75M after load ircwarpzilla.html
159.46M after load ircevangelism.html in a new tab
158.27M after load ircchatzilla.html in a new tab
152.67M after load ircmozillazine.html in a new tab (load time est 18 sec)
149.27M after load ircmozilla.html in a new tab (load time 23 sec)
146.44M after load ircmozillazine.html in a new tab (load time 20 sec)
143.15M after load ircmozilla.html in a new tab (load time 23 sec)
140.57M after load ircmozillazine.html in a new tab (load time 19 sec)
137.14M after load ircmozilla.html in a new tab (load time 23 sec)
134.53M after load ircmozillazine.html in a new tab (load time 20 sec)
131.06M after load ircmozilla.html in a new tab (load time 24 sec)
193.24M free after shutdown browser
***
These are in 1.4.1 browser on Fedora 0.95 (one per tab):
22516K Empty browser consumption
26660K #warpzilla loaded
27476K #evangelism loaded
28344K #chatzilla loaded
33000K #mozillazine loaded
35984K #mozilla loaded

So, just for loading the 5 tabs' content into an empty browser, OS/2 is using
about 23% more RAM, and it only gets worse with use.

Note that the file with unbroken long line is only marginally larger than the
other large with <tr> on individual lines, but takes about 15% longer to load.

Comment 8

[Felix Miata]

Attachment: 357109 byte #mozilla 208 lines (long line mostly unbroken)

These were collected according to comment 1. Here's the result of loading them
in in 2003110308 OS/2 trunk browser:
***
193.9M free before startup browser
166.4M free after startup browser
159.8M after load ircchatzilla.html
158.8M after load ircevangelism.html in a new tab
152.8M after load ircmozilla.html in a new tab
150.07M after load ircmozillazine.html in a new tab
149.99M after load ircwarpzilla.html in a new tab
193.3M free after shutdown browser
***
193.33M free before startup browser
166.15M free after startup browser
160.50M after load ircwarpzilla.html
159.26M after load ircevangelism.html in a new tab
158.06M after load ircchatzilla.html in a new tab
153.79M after load ircmozillazine.html in same tab
150.18M after load ircmozilla.html in a new tab
193.34M free after shutdown browser
***
193.34M free before startup browser
166.15M free after startup browser
160.69M after load ircwarpzilla.html
159.40M after load ircevangelism.html in a new tab
158.09M after load ircchatzilla.html in a new tab
152.86M after load ircmozillazine.html in a new tab
149.05M after load ircmozilla.html in a new tab
193.35M free after shutdown browser
 44.30M net consumption (one each of all five)
***
193.35M free before startup browser
166.22M free after startup browser
160.75M after load ircwarpzilla.html
159.46M after load ircevangelism.html in a new tab
158.27M after load ircchatzilla.html in a new tab
152.67M after load ircmozillazine.html in a new tab (load time est 18 sec)
149.27M after load ircmozilla.html in a new tab (load time 23 sec)
146.44M after load ircmozillazine.html in a new tab (load time 20 sec)
143.15M after load ircmozilla.html in a new tab (load time 23 sec)
140.57M after load ircmozillazine.html in a new tab (load time 19 sec)
137.14M after load ircmozilla.html in a new tab (load time 23 sec)
134.53M after load ircmozillazine.html in a new tab (load time 20 sec)
131.06M after load ircmozilla.html in a new tab (load time 24 sec)
193.24M free after shutdown browser
***
These are in 1.4.1 browser on Fedora 0.95 (one per tab):
22516K Empty browser consumption
26660K #warpzilla loaded
27476K #evangelism loaded
28344K #chatzilla loaded
33000K #mozillazine loaded
35984K #mozilla loaded

So, just for loading the 5 tabs' content into an empty browser, OS/2 is using
about 23% more RAM, and it only gets worse with use.

Note that the file with unbroken long line is only marginally larger than the
other large with <tr> on individual lines, but takes about 15% longer to load.

Comment 9

[Felix Miata]

I tried loading the two big files in 1.5 on Mandrake KDE (different machine, but
same CPU type and speed, same total RAM, and via samba, from the same disk as OS/2):
mozillazine.html 10.0,9.3, 9.3, 9.7 (ignoring high and low, 9.50 avg)
mozilla.html 9.9, 10.1, 10.6, 10.2 (ignoring high and low, 10.15 avg)

This difference isn't terribly unlike the the OS/2 test, so, it appears there
would be some speed to be gained if the live CZ HTML table code could be broken
into smaller pieces.

Comment 10

[Felix Miata]

I can't think of any good way to quantify this, but simply using the scrollback
on a busy channel can cause significant additional RAM consumption.

Comment 11

[Felix Miata]

I opened a 1.5 on W98 browser window with homepage, then 0.9.35 with warpzilla,
mozilla, mozillazine, chatzilla & evangelism on moznet. After 8 hours uptime,
total RAM release on shutdown was 33M (193M free v. 160M free, out of 256M total).

Comment 12

[Robert Ginda]

I agree that chatzilla's html output could be made quite a bit smaller, but I'd
suggest that be the issue of another bug.

Are there any takers from the os/2 team for this bug?

Comment 13

[jhp (no longer active)]

Leave this open.  We'll try to take a look at this soon.

Comment 14

[Felix Miata]

This may not be reproducable on systems with suboptimal RAM. I opened CZ & Moz
trunk over 3 days ago on a system with 128M of RAM, and the swapper has not been
touched. My 24/7 system has 256M RAM, and CZ on it will still run RAM down to
524288 bytes or so, after which new RAM requests from any other app will grow
the swapper.

Comment 15

[Felix Miata]

Something must have made this worse. 2004011408 only took 20 hours to run free
RAM down to 1/2M on this 256M system. In CZ I had 6 channels open on moznet the
whole time, and 1 channel on another server for about the last 8 hours. During
the 20 hours, I was away for about 8 hours, and asleep about 6. Closing Moz
entirely freed 172M of RAM.

Comment 16

[Christoph Bratschi]

I don't use Chatzilla but I've problems with the memory usage too.

If I start Mozilla 1.4.1 (20031125, 20040124, 20040131) with 4 tabs open,
Mozilla uses 60 MBytes. After opening the mail component, it uses 60 MBytes in
addition. After that the memory consumption is more or less constant. Opening 20
additional windows takes roughly 40 MBytes.

I wonder why the main application and the mail component need so much memory.
And the memory, of coure, is only freed if Mozilla exits.

On Linux and Windows Mozilla uses less memory.

Comment 17

[Felix Miata]

Since I can't even run Moz 20 hours any more without having all my free memory
evaporate, I can't even go from one nightly build to the next without an
otherwise unnecessary restart. Rather than doing anything about it in response
to reminders on #chatzilla, the Chatzilla owner has chosen to ban me from there
instead.

Comment 18

[Robert Ginda]

We've explained to you that this is a problem with your port, and not chatzilla
itself.  There's nothing I'm going to be able to do about this.  And unless one
of the other members of #chatzilla finds an os/2 box in their closet, I don't
think they're going to help you either.

Comment 19

[Felix Miata]

Since CZ is nothing but JS & chrome, it seems obvious the bug isn't in CZ
itself, but something CZ is making Moz do that it doesn't do well, which may or
may not be entirely the fault of the port. In addition to this bug, bug 199569,
if not others too, points to inefficiency with CZ's foundation, large tables.
The CZ people could at least help instead of merely bad-mouthing the port
(rginda: "I'm tired of hearing him blame chatzilla for his crappy platform")  by
reassigning this to some component likely to be responsible, such as Layout, DOM
or JS Engine.

Comment 20

[Robert Ginda]

Maybe you missed the part where this was only a problem on os/2?  You're free to
reassign this bug to whatever component you think is correct.

Comment 21

[James Ross]

Felix, as part of the DCC Chat implementing, I'm expecting to re-write the
display routine to use significantly less HTML attributes. If this is one of the
things the OS/2 port is having trouble with, it may well help the memory
problem; though it obviously won't "fix" it, only reduce it's impact.

Comment 22

[Felix Miata]

I'm sure someone intimately familiar with the workings of CZ and at least some
familiarity with programming, such as Robert Ginda, would have done a better job
picking a component to move this to.

Comment 23

[Mike Kaply [:mkaply]]

Are you trying to piss Robert off?

Comment 24

[Felix Miata]

I started up yesterday's VACPP 1.4.2 instead of the GCC trunk nightly yesterday.
RAM freed by shutdown of Moz/CZ/Mailnews after 24 hours uptime was 118M, much
less than the ~200M used by GCC trunk builds lately in 20 hours or less.

Comment 25

[Felix Miata]

I ran OS/2 GCC trunk 2004021408 24 hours without opening CZ even once. Open tab
count was as high as 25, including many buglists. I retrieved mail and read
netscape.public.mozilla.os2 several times, similiar to what I did in comment 24
VACPP build. RAM released on close was {drumroll} 118K.

Comment 26

[Felix Miata]

In 1.7a release, memory recovery on shutdown: 162M. Total suite uptime 10 hours,
of which less than 6 included CZ (and seeing bug 226965 for the first time), and
overall was a bit lighter duty than average.

Comment 27

[Felix Miata]

I opened 2004022908 OS/2 trunk on my new P4 yesterday morning. The P4 is
equipped with a cloned HD from my old K6/3. I changed only IP and nick. I ran
browser, mailnews, and CZ normally for 24 hours:

442372096 Free RAM after shutting down Moz
301936640 Free RAM immediately before shutting down Moz
140435456 RAM recovered

Looks like bug 235410 fix may have fixed this. I wish there was a build from the
day after that checkin to test, and just started up the old machine with the
2004022908 trunk to verify this isn't hardware related.

Comment 28

[Felix Miata]

After the past 24's results, I still can't be sure bug 235410 helped or fixed:

Machine               Celeron 2.4G     K6/3-550
Build                  2004030108     2004022908
Browser usage        Avg++ (bug day)         Avg--
Free after closing        439836672      184709120
Free before closing       234872832       57872384
Freed                     204963840      126836736

Will watch normal non-bugday usage a while & report again.

Comment 29

[Felix Miata]

A few weeks ago, the size of the Mozilla download decreased noticably. About
that time, memory consumption seemed to drop some. I just closed 2004040708
after 36 hours uptime on the P4, and recovered 133,132,288 bytes. 

Comment 30

[Felix Miata]

Looks like this has probably become respectable enough. I just ran Sunday's OS/2
trunk on my old machine, CZ 0.9.61 only for 24 hours, 7 channels on moznet. RAM
release on close was 52,416,512. 20040411 on Linux after 24 hours of CZ 0.9.61
according to top is using 37,900K, with only 6 of those same 7 channels (no
#bs). I just started 1.7b on Win98 now to see how it does in 24 hrs with all 7
channels (should be higher than average because of bugday on #mozillazine).

I would have run Win98 simultaneous with the other two, but moznet has a client
connect per IP limit of 3, and the one on this machine needs remain in normal
use while the others are testing.

Comment 31

[Felix Miata]

I just ran 1.7b on Win98, CZ 0.9.61 only for 24 hours, same 7 channels on moznet
as the day before tests on OS/2. RAM release on close was 37,542,936. 20040411
on Linux after 24 hours of CZ 0.9.61 according to top is using 40,420K, with the
same 7 channels.

Comment 32

[Felix Miata]

After 120 hours uptime on OS/2 1.7rc1b (browser/mail/0.9.61), RAM released on
close: 260,968,448.

Comment 33

[Wayne Mery (:wsmwk)]

is this still the case with 1.0b or current trunkbuilds (with gecko 1.8)?  cc: Larry

Comment 34

[Larry Belan]

Since I was CC'd in:

I don't use the CZ component, so I don't believe that I can comment on this leak issue.  So far, just running 20051031 trunk build, and nothing out of the ordinary there.

Comment 35

[Felix Miata]

Yesterday I shut down about 15 CZ tabs, 25 browser tabs, and mailnews 2003110305 trunk after 74.5 hours uptime. RAM recovered was 224,813,050. I opened 2005110805 about 24 hours ago. Opening 25 tabs in browser consumed 124,919,810, mailnews into local mail and netscape.public.mozilla.os2 another 27,140,100. Total used with 15 CZ tabs open is now around 200,638,470.

Comment 36

[James Ross]

I just want to point out that as soon as any other component is involved (e.g. browser, mailnews, etc.), the figures are completely meaningless. You really need to run only ChatZilla and measure that.

Comment 37

[Felix Miata]

At 09:02 EST I opened CZ exclusively in OS/2 2005111005 trunk, with auto open for 13 tabs, plus one server tab and one query tab. Because Friday afternoon things get slow on moznet, to pad up consumption a bit to compensate 30 minutes ago I opened two additional tabs for busy channels, #firefox and #bugs. Free RAM prior to close: 257M. Free RAM after close at 17:08 EST: 326M. Freed: 69M.

Comment 38

[Peter Weilbacher]

Did you ever try to run the same Chatzilla setup in parallel on OS/2 and another system and just leave it alone for two hours or so while touching no webpages at all? Only that way you will get comparable results. I always meant to try that but I never even find time to visit IRC in a normal way...

Another idea would be to run Theseus' leak monitor and check in which modules allocations occur.

Comment 39

[Wayne Mery (:wsmwk)]

I'm seeing 50MB/24hr - 10 moz channels, scrollback=3500, #seamonkey is logged.

James, what do you suggest be monitored/logged/traced to help narrow the problem?

Comment 40

[James Ross]

The memory usage while views have less lines than their limit is of little interest, compared with once they have reached the limit. For obvious reasons, 3500 lines of DOM table is going to be a lot of individual elements, attributes, and resolved CSS styles; what would be interesting is whether the rate of "leak" changes once the scrollback limit has been reached, and if so, by how much.

Comment 41

[Peter Weilbacher]

The number that Wayne posted last summer doesn't sound like much which suggests that this really was/is an OS/2 only problem (as it is still marked). Especially as jemalloc is now used on the other platforms.

I rarely get to IRC but I recently did for a few hours and the memory consumption with that trunk build (SeaMonkey ~2008-04-02) was not too high and most of it was freed after I closed the CZ window. So, is this still an issue with current trunk builds?

Comment 42

[Felix Miata]

(In reply to comment #41)
> So, is this still an issue with current trunk builds?

I really don't know if there's any way for me to test this. I keep SM 1.0.x up for days at a time, with lots of tabs and 1000 emails a day. Is OS/2 trunk RAM leakage down to a level that might permit 4-5 days' uptime without grinding the system to a halt or crashing SM during a mail fetch or compose?

Comment 43

[Peter Weilbacher]

Real leakage on trunk should be far better than on branch but I can't say anything about uptimes of several days.

Comment 44

[Wayne Mery (:wsmwk)]

iirc my memory change could be explained by the effect of logging. And I am no longer able to test this out.

Comment 45

[:Gijs (he/him)]

I don't want to be mean, but, what are we supposed to do with a bug that's 5 years old and has no clear problem description? Shouldn't this just be WFM/INVALID? If not, can someone post an up-to-date problem description with clear steps to reproduce and some kind of metric of when they would consider this bug FIXED? (as in, what the expected behaviour is). Shifting this from one component to the other without any comments about why feels a bit random to say the least.

Comment 46

[Peter Weilbacher]

Yes, we still have no data that could tell us where to start debugging, so this is impossible to attack. Additionally, all the data that is there is now years old and doesn't apply to Gecko 1.9+ any more. --> invalid

Felix: if you ever find time to take a leak log (with the Theseus tool) of a Chatzilla session, you could file a new bug. As I said before, as side-by-side comparison of memory consumption with time on a non-OS/2 system with the same session could help, too. But in the end I guess we'll never be able to fix this, if it's still a problem.