Closed Bug 324081 Opened 19 years ago Closed 15 years ago

Seamonkey doesn't release memory upon closing tabs

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: elst93, Unassigned)

Details

(Keywords: testcase, Whiteboard: closeme 2009-07-14)

Attachments

(1 file, 1 obsolete file)

Browser Mem Buster Test v0.3
6.29 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060117 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060117 SeaMonkey/1.5a

When I start up seamonkey from scratch it takes up around 19MB of memory. Opening more tabs won't increase the memory usage much, maybe by 5MB. 

But as soon as I close the tabs, the memory usage increases exponentially. Each tab opened and closed after that increases the actual memory use, up to where I have had Seamonkey crash at using 180MB. 

Reproducible: Always

Steps to Reproduce:
Start Seamonkey, start Windows Task Manager. 
Note how much memory is used. 

Open lots of tabs. Close them one by one, while checking Task manager inbetween. 
Memory use will go up and stay up. It won't "release" the memory of the tabs/pages just closed.
Version: unspecified → Other Branch
Please use the new leak logging facility as described here:
http://weblogs.mozillazine.org/seamonkey-qa/archives/2006/01/help_find_leaks_in_seamonkey.html
For windows, you might find it more convenient to use the DHTML version of the processing script here:
http://dbaron.org/log/2006-01#d20060114

Please make sure you test with no extensions installed.  The extensions can either expose leaks or leak all on their own.
Version: Other Branch → Trunk
Ok, I have now tried 3 times in 3 days to get this leak script to work. Even with a friend versed in Perl. I have ActivePerl installed, I set the variables through the command line. 

No log file is being made. 
My friend tried it with his Firefox install. At first it wouldn't make a log either, but in the end it did. I am still waiting patiently. We set it up equally. 

So either it won't work with Seamonkey, or it won't work with Activeperl, or I set things differently than others. I am about to give in and just update, waiting for a version that won't leak memory this much. 

I would assume there's an easier way for this to be handled, but for through a perl script. As that means people have to install Perl on their machines. And then figure out what's meant in the extremely small How To in the script. 

Can't Windbg handle it? 
> So either it won't work with Seamonkey, or it won't work with Activeperl

I've been using in with SeaMonkey (but on linux).  

> I would assume there's an easier way for this to be handled, but for through a
> perl script. 

Yes, there's a non-perl alternative in the second link in my comment
http://dbaron.org/log/2006-01#d20060114
uhm yes, but then I still have the problem of setting the variables. 

I have set the two lines in a batch file on my desktop. 
or should the command line option stay open? 

When is the *.log file made? Upon opening up Mozilla or upon closing it? 
(In reply to comment #4)
> uhm yes, but then I still have the problem of setting the variables. 
> 
> I have set the two lines in a batch file on my desktop. 
> or should the command line option stay open? 
> 
> When is the *.log file made? Upon opening up Mozilla or upon closing it? 
> 

Are you launching SeaMonkey from the same cmd window that you ran the "set" command in?  You have to, if you're not.  The log file is created at launch, and updated as you use the browser.
Jorden van der Elst, read thru Bug 320915 if memory leak is suspectable, and see Bug 320915 Comment #28.
If problem occurs even when no extention, and if problem occurs even when bfcache is disabled, and if no error report by Leak Gauge, and if Mail&News use is involved in your problem, see Bug 329876.

(In reply to comment #4)
> should the command line option stay open? 
Yes. As Chris Thomas says, all of nexts should be done at same command prompt.
 (1) SET NSPR_LOG_MODULES=...
 (2) SET NSPR_LOG_FILE=...
 (3) <Your_Semonkey's_Program_Library_Path>\semonkey.exe -p


I see the same effect for mozilla-based browsers on Linux: Seamonkey 1.0, Seamonkey 1.5a, Firefox 1.0.*, Firefox 1.5. 

Seamonkey-bin (firefox-bin) VM size monotonically increases while opening new tabs, URLs, windows and never goes down upon closing them.

YES: browser.cache.memory.enable = false, 
     browser.cache.disk.enable   = false, 
     no extensions, no plugins

Noticeably, the leak-gauge tool (http://lxr.mozilla.org/mozilla/source/tools/footprint/leak-gauge.pl?raw=1) shows 0 leaked objects after shutting down the browser.

PS: on Windows 2000, Firefox 1.* and indeed releases memory: its VM size returns to the amount one records upon having started the browser with about:blank page.

Problem seems to be Linux specific!

(In reply to comment #7)
> I see the same effect for mozilla-based browsers on Linux: Seamonkey 1.0,
> Seamonkey 1.5a, Firefox 1.0.*, Firefox 1.5. 
> 
> Seamonkey-bin (firefox-bin) VM size monotonically increases while opening new
> tabs, URLs, windows and never goes down upon closing them.
> 
> YES: browser.cache.memory.enable = false, 
>      browser.cache.disk.enable   = false, 
>      no extensions, no plugins
> 
> Noticeably, the leak-gauge tool
> (http://lxr.mozilla.org/mozilla/source/tools/footprint/leak-gauge.pl?raw=1)
> shows 0 leaked objects after shutting down the browser.
> 
> PS: on Windows 2000, Firefox 1.* and indeed releases memory: its VM size
> returns to the amount one records upon having started the browser with
> about:blank page.
> 
> Problem seems to be Linux specific!
> 

Could you run the leak gauge tool after closing all but one tab, but with the browser still running, and see if it reports only a couple leaks then, or a lot of leaks?
(In reply to comment #8)
> Could you run the leak gauge tool after closing all but one tab, but with the
> browser still running, and see if it reports only a couple leaks then, or a lot
> of leaks?
> 

Statistics of VM usage/object leak  during the seamonkey session is as follows:

Immediately after start with about:blank :
--------------------------------------------
Leaked 6 out of 6 DOM Windows
Leaked 23 out of 24 documents
Leaked 3 out of 3 docshells
.....................................................................
  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
 9592 pts/4    S      0:01   3309   233 33886 20476  1.9 seamonkey-bin
 9595 pts/4    S      0:00      1   233 33886 20476  1.9 seamonkey-bin
 9596 pts/4    S      0:00      2   233 33886 20476  1.9 seamonkey-bin
 9599 pts/4    S      0:00      0   233 33886 20476  1.9 seamonkey-bin
=======================================================================

Upon opening multiple tabs and windows:
----------------------------------------------------------------------
Leaked 108 out of 157 DOM Windows
Leaked 76 out of 130 documents
Leaked 54 out of 55 docshells
.....................................................................
  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
 9592 pts/4    S      0:31   3679   233 76606 61740  5.9 seamonkey-bin
 9595 pts/4    S      0:00      1   233 76606 61740  5.9 seamonkey-bin
 9596 pts/4    S      0:01      9   233 76606 61740  5.9 seamonkey-bin
 9599 pts/4    S      0:00      0   233 76606 61740  5.9 seamonkey-bin
10211 pts/4    S      0:00      0   233 76606 61740  5.9 seamonkey-bin
=====================================================================

Upon closing all tabs/windows except for the one with about:blank :
------------------------------------------------------------------
Leaked 10 out of 166 DOM Windows
Leaked 28 out of 141 documents
Leaked 3 out of 59 docshells
.......................................................................
  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
 9592 pts/4    S      0:36   3720   233 75214 60244  5.8 seamonkey-bin
 9595 pts/4    S      0:00      1   233 75214 60244  5.8 seamonkey-bin
 9596 pts/4    S      0:01      9   233 75214 60244  5.8 seamonkey-bin
 9599 pts/4    S      0:00      0   233 75214 60244  5.8 seamonkey-bin
10376 pts/4    S      0:00      0   233 75214 60244  5.8 seamonkey-bin
=======================================================================

Upon shutting down seamonkey :
--------------------------------------------
Leaked 0 out of 166 DOM Windows
Leaked 0 out of 141 documents
Leaked 0 out of 59 docshells
.........................................
=============================================

Build: seamonkey-1.5a, en-US, linux-i686-gtk1, 09-Mar-2006.
OS:    GNU/Linux, 2.4.29, glibc-2.3.6 (the same behavior is observed on _any_ linux system)

> Immediately after start with about:blank :
> --------------------------------------------
> Leaked 6 out of 6 DOM Windows
> Leaked 23 out of 24 documents
> Leaked 3 out of 3 docshells

That's to be expected.  The results don't really mean anything until you close SeaMonkey, which in your case had no leaks.
(In reply to comment #10)
> > Immediately after start with about:blank :
> > --------------------------------------------
> > Leaked 6 out of 6 DOM Windows
> > Leaked 23 out of 24 documents
> > Leaked 3 out of 3 docshells
> 
> That's to be expected.  The results don't really mean anything until you close
> SeaMonkey, which in your case had no leaks.
> 

Please, look at the column after "Upon closing all tabs/windows except for the one with about:blank" :

>Leaked 10 out of 166 DOM Windows
>Leaked 28 out of 141 documents
>Leaked 3 out of 59 docshells
>........................................
>  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
> 9592 pts/4    S      0:36   3720   233 75214 60244  5.8 seamonkey-bin


Memory and disk caches are *off*. 
We start at about:blank with VM ~ 20M and finish at about:blank again but with ~60M of VM. 
What are those ~40M are used for?

On Windows2000 one ends up here with the initial VM size of ~20M instead of 60.
(In reply to comment #10)
> > Immediately after start with about:blank :
> > --------------------------------------------
> > Leaked 6 out of 6 DOM Windows
> > Leaked 23 out of 24 documents
> > Leaked 3 out of 3 docshells
> 
> That's to be expected.  The results don't really mean anything until you close
> SeaMonkey, which in your case had no leaks.
> 

I asked him to check this because I'd seen before that I wasn't leaking (much) but was getting lots of memory usage, and dbaron suggested it might be worth checking to see if a whole bunch of things are hanging around until you actually quit.
(In reply to comment #12)
> I asked him to check this because I'd seen before that I wasn't leaking (much)
> but was getting lots of memory usage, and dbaron suggested it might be worth
> checking to see if a whole bunch of things are hanging around until you
> actually quit.
> 

Thus, if a massive ``hanging'' of objects until the quit is not here, then could a non-decreasing VM size be a consequence of PR_*alloc, PR_Free implementation on Linux? 

I'm sorry to repeat: on Linux, this VM size issue takes place for all mozilla-based browsers (including Netscape 7), while on Windows 2000 they always release VM in a reasonable manner.



> could a non-decreasing VM size be a consequence of PR_*alloc, PR_Free

PR_*alloc and PR_Free map directly to C calls to *alloc and free except on Win 3.1.

You might be seeing bug 130157
(In reply to comment #9)
You are saying that virtual storage is not freed(not returned to OS) after step (3), and suspecting "memory leak".
> (1) VS1 : Immediately after start with about:blank :
> (2) VS2 : Upon opening multiple tabs and windows:
> (3) VS3 : Upon closing all tabs/windows except for the one with about:blank :

Same question as Bug 327418 Comment #14 :   
  What happens on virtual sotrage size when next steps are executed?
  (4) VS4 : Open  multiple tabs and windws ( same as spep(2) )
  (5) VS5 : Close multiple tabs and windws ( same as step(3) )
  (6) Repeat (4) and (5)
Will virtual storage size increase infinitely?
If VS4>>VS2, and if virual storage size largely increases on every step (6), memory leak is suspectable. But if VS4 is not so larger than VS2, it indicates that virual memory is re-used(usually heap is not freemain'ed but re-used), then no large memory leak is involved, and increase from VS1 to VS3 is guessed as simpley a result of other issue such as bug 130157, as Andrew Schultz says. 

> Immediately after start with about:blank :
>  (a) Leaked   6 out of   6 DOM Windows
> Upon opening multiple tabs and windows:
>  (b) Leaked 108 out of 157 DOM Windows
> Upon closing all tabs/windows except for the one with about:blank :
>  (c) Leaked  10 out of 166 DOM Windows
Increase from 6 at (a) to 10 at (c) is suspectable as a result of leak of something.
But destorying object is not always done just after Tab/Window close. (Including  similarity to "garbage collector is not invoked just after destory object".)
In addition to it, NSPR log data is probably buffered, then log for destroy object can be kept in buffer when you run Leak Gauge tool.
 (This probably can be avoided by getting log of nsSocketTransport:5 same time)
 (because many many polling logs during idle are written by it.               )
 (See http://www.mozilla.org/projects/netlib/http/http-debugging.html         )
These are one of reasons why termination is required to use Leak Gauge tool.

O.V.Zenin, please be very carefull in using current "DOMLeak:5, DocumentLeak:5, nsDocShellLeak:5 and Leak Gauge tool combination" without termination, as leak detection tool.
(In reply to comment #0, in addition to my comment #6)
> But as soon as I close the tabs, the memory usage increases exponentially. Each
> tab opened and closed after that increases the actual memory use, up to where I
> have had Seamonkey crash at using 180MB. 

Because memory or resource management mechanism is different when bfcache, and because current memory cache size default is determined based on physical memory size, it is very difficult to check "whether memory leak is involved or not" by external obserbation of virtusl sotrage size only.
So at least next two are required usually when observation, in addition to test with new profile(no extention) and test with newest trunk.
 (1) Set memory cache size manually, and keep same size among testing.
 (2) Check both 2 cases, bfcache=disabled case and bfcache=enabled case.
     - Set browser.sessionhistory.max_viewers=0(disabled) or M(enabled)
     - browser.sessionhistory.max_total_viewers=0(disabled) or N(enabled)
       (default of both option is "-1", determined by memory size)
(In reply to comment #15)

I guess, the observed VM growth has nothing to do with any 'true' leaks, it rather concerns a behaviour of the glibc memory allocator.

Look at the malloc_stats() output:

1. Upon having started with about:blank:

Arena 0:
system bytes     =    7286784
in use bytes     =    7277968 
Total (incl. mmap):
system bytes     =    7286784
in use bytes     =    7277968 <==== U1
max mmap regions =          1
max mmap bytes   =     184320

2. After opening ~25 tabs from http://news.bbc.co.uk/... :

Arena 0:
system bytes     =   41541632
in use bytes     =   32927176  
Arena 1:
system bytes     =    3837952
in use bytes     =     183160
Total (incl. mmap):
system bytes     =   45379584
in use bytes     =   33110336 <==== U2
max mmap regions =          1
max mmap bytes   =     184320

3. Upon closing all the tabs and leaving one blank tab:
Arena 0:
system bytes     =   41447424
in use bytes     =    9261256 
Arena 1:
system bytes     =    3837952
in use bytes     =     149304
Total (incl. mmap):
system bytes     =   45285376
in use bytes     =    9410560 <==== U3
max mmap regions =          1
max mmap bytes   =     184320

[Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060311 Firefox/1.0.7], all disk and memory caches set to 'false'.

Note that U3=9410560 b << U2=33110336 b  and U3 ~ U1 as expected, while
the total memory allocated from OS never drops.

Thus, the total VM size of the process never significantly decreases, perhaps due to a non-compactification of the heap. Should the browser use its own memory allocator instead of the glibc's one ?

mlk keyword?
If it's worth it to know, I have the same problem on Win XP.


*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #19)
> If it's worth it to know, I have the same problem on Win XP.
> 

Oh, I'm reporting this about SeaMonkey 1.0.1.
The same behaviour on GNU/Linux is observed for Seamonkey 1.0.1, Mozilla 1.8b and Firefox 2.0a("bonecho") with

browser.cache.memory.enable = false 
browser.cache.disk.enable       = false

E.g., for Firefox 2.0a one finds the following VM footprint during the session (note the RSS column):

      PID     TTY  STAT  TIME  MAJFL   TRS   DRS        RSS  %MEM COMMAND
(1) 32575 pts/6   S       0:02    3769      9712   90827   23100       4.5   ./firefox-bin
(2) 32575 pts/6   S       0:26    4074      9712 128519   59708     11.6   ./firefox-bin
(3) 32575 pts/6   S       0:42    4108      9712 128515   60004     11.7   ./firefox-bin

(1) - upon start with about:blank
(2) - upon opening ~30 tabs from http://news.bbc.co.uk/..
(3) - upon closing them all and opening about:blank again

P.S. I'm sorry to repeat again and again: this pattern of VM consumption is typical for ALL mozilla-based browsers on GNU/linux and has nothing to do with any true memory leaks (see, e.g., comment #17 with the output of malloc_stats() above). 

On Linux, Mozilla-based browsers URGENTLY need a custom memory management aimed at returning unused memory to OS.

Then perhaps this is a bug in the core, rather than specifically SeaMonkey?
There's already a bug on file for freed memory not being returned to the system: bug 130157
(In reply to comment #23)
> Then perhaps this is a bug in the core, rather than specifically SeaMonkey?
> 

Certainly, all Gecko-based browsers on Linux suffer from this bug, including netscape-7, galeon, epiphany, etc.
(In reply to comment #1)
> Please use the new leak logging facility as described here:
> http://weblogs.mozillazine.org/seamonkey-qa/archives/2006/01/help_find_leaks_in_seamonkey.html
> For windows, you might find it more convenient to use the DHTML version of the
> processing script here:
> http://dbaron.org/log/2006-01#d20060114
> 
> Please make sure you test with no extensions installed.  The extensions can
> either expose leaks or leak all on their own.
> 

i have the same bug!
Perhaps, the OS field in the bug description should be changed to "All".

Disclaimer: yes, I know that at least on Windows 2000 SP4 and OpenBSD 3.8/3.9 this bug does not actually show up due to "multiple-heap" memory management implemented in runtime libraries there.

A remark from the GNOME project may be useful:

http://live.gnome.org/MemoryReduction/#overview

> Disclaimer: yes, I know that at least on Windows 2000 SP4 and OpenBSD 3.8/3.9
> this bug does not actually show up due to "multiple-heap" memory management
> implemented in runtime libraries there.

Some good news for Linux users as well.

The OpenBSD 3.9 default memory allocator is adopted for GNU/Linux:

http://mr.himki.net/OpenBSD_malloc_Linux.c

Though the port is yet unstable and reported to work decently only on several Linux distributions, mozilla-based browsers DO RELEASE MEMORY IN EXPECTED AMOUNTS when launched with this purely mmap-based allocator. 
The original source of the OpenBSD allocator is http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libc/stdlib/malloc.c?rev=1.83&content-type=text/plain

The patch to be applied to the latter to obtain the Linux version:

http://mr.himki.net/OpenBSD_malloc.patch
(In reply to comment #27)
> Perhaps, the OS field in the bug description should be changed to "All".
> 
> Disclaimer: yes, I know that at least on Windows 2000 SP4 and OpenBSD 3.8/3.9
> this bug does not actually show 

A correction: on Windows 2000 and XP the bug actually shows up. 

As far as I know, OpenBSD is the only OS on which Mozilla-based browsers release memory to kernel in expected amounts.


(In reply to comment #30)
> A correction: on Windows 2000 and XP the bug actually shows up. 
 
> As far as I know, OpenBSD is the only OS on which Mozilla-based browsers
> release memory to kernel in expected amounts.

O.V.Zenin, could you read Bug 320915 Comment #42 to Bug 320915 Comment #47, please.
OS: Windows 2000 → All
Product: Mozilla Application Suite → Core
I'm also seeing a serious memory problem with trunk builds.

After running the Browser Mem Buster Test v0.2, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060921 Minefield/3.0a1 consumes over 360 MB of memory as reported by the VM Size column in the Windows Task Manager. Recent SeaMonkey 1.1 branch builds consume under 130 MB after the same test.

After running the test and closing all but the first tab in Firefox trunk builds, leak-gauge.pl reports:
Summary:
Leaked 24 out of 4053 DOM Windows
Leaked 34 out of 2842 documents
Leaked 4 out of 1444 docshells

about:cache reports:
Memory cache device
Number of entries: 	512
Maximum storage size: 	18432 KiB
Storage in use: 	16451 KiB
Inactive storage: 	16142 KiB

After closing Firefox, leak-gauge.pl reports:
Summary:
Leaked 0 out of 4054 DOM Windows
Leaked 0 out of 2843 documents
Leaked 0 out of 1444 docshells

It appears as though the excess memory is not used by DOM Windows, documents, docshells, or images.
Attached file Browser Mem Buster Test v0.2 (obsolete) — 

    
    

    
  


  
This is a more robust version of the Browser Mem Buster Test.

It may be that the excessive memory usage is caused by Flash content on the pages (bug 354087). After the test is complete, memory usage continues to increase, I think because of the active Flash content on the tabs that remain open.

        Attachment #239643 -
        Attachment is obsolete: true

    
    

    
  
now almost 3 years since last touch, this needs a retest.
Status: NEW → UNCONFIRMED
Whiteboard: closeme 2009-07-14

    
    

    
  
Was this partially fixed by jemalloc?

    
    

    
  
(In reply to comment #36)
> Was this partially fixed by jemalloc?

a similar bug was closed  as you hint - bug 130157.  however, this bug has a testcase, so it should be tested before closing, or whatever else happens to it.
Assignee: general → nobody
Keywords: testcase
QA Contact: general → general

    
    

    
  
I ran the test for an hour.  The memory useage leveled off at a reasonable state and didn't dramaticlly increase.  Tomcat has been doing regular and extensive leak testing and filing of specific bugs per leak.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: