391507 - Memory leaks and failure to shut down

Status: RESOLVED INVALID

(SeaMonkey :: General, defect)

Description

[Sune Mølgaard]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.5) Gecko/20070716 SeaMonkey/1.1.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.5) Gecko/20070716 SeaMonkey/1.1.3

For a very long time, I have been forced to close seamonkey down in intervals ranging from 2 to 4 days, as it ends up using most of my 2Gb of RAM and 4Gb of swap space.

Furthermore, upon closing, the main process isn't actually killed, but needs to be so via the command 'kill'.

I am at a loss as how to diagnose, but will happily do so, if I get some feedback on how to proceed.

Reproducible: Always

Steps to Reproduce:
1. Use seamonkey, and let it run for a few days.
2. Check memory consumption (most of all available).
3. Close seamonkey.
4. Verify via "ps ax|grep seam" that processes are still running.
5. Kill the main process via "kill"
Actual Results:  
Seamonkey eats a lot of ram and fails to exit when necessarily asked to.

Expected Results:  
No leaking, so that seamonkey may run as long as the system does, using RAM for the open views, but releasing it again, when a tab is closed.

Actually quitting when asked to do so...

Comment 1

[Wayne Mery (:wsmwk)]

Sune, does this improve if you do both of the following
1. ensure you have the latest flash plugin for linux?
2. install flashblock extension?

In reply to comment #0)
> For a very long time, I have been forced to close seamonkey down in intervals
> ranging from 2 to 4 days, as it ends up using most of my 2Gb of RAM and 4Gb of
> swap space.
...
> Expected Results:  
> No leaking, so that seamonkey may run as long as the system does, using RAM f

2-4 days would not bad with branch build, 1 week and you are doing really well

Comment 2

[Sune Mølgaard]

Hi Wayne, and thanks for answering,

With regards to the failure to shut down, this has almost vanished with later builds, though I assumed the problem to still be present, as it takes some time for the actual exit to occur. Thus, that part of the problem may be disregarded.

I am not entirely sure what flashblock does. Does it block all flash, or just flash ads? As you may surmise, I haven't tried it yet, but the flash player  is latest version.

As per 

>2-4 days would not bad with branch build, 1 week and you are doing really well

that sounds really bad. I certainly don't find that acceptable, even though I am immensely pleased with all aother aspects of seamonkey, so I hope some better coder/detective than me will look into this at some point in the future.

In the meantime, I should like the memory consumption over time to be confirmed as a bug, in order for someone to pick it up.

Best regards,

Sune Mølgaard

Comment 3

[Wayne Mery (:wsmwk)]

>I should like the memory consumption over time to be confirmed as a bug, in order for someone to pick it up.

Sune, until the circumstances or the cause have been identified and are reproducible by someone else, and not a duplicate of some other bug, there is really nothing here to warrant confirming (more or less the definition of NEW). 


>I am not entirely sure what flashblock does. Does it block all flash

yes, all flash. you get to choose manually what gets displayed.  500k-1gb usage is easily caused by multiple flash images over a long period of time.


> No leaking, so that seamonkey may run as long as the system does

this isn't going to happen in a gecko 1.x based browser.  suggest youdo the flashblock extension.  If it's enough then close this bug invalid. If not your simplest choices are:
1. if you are dying to solve this problem and willing to put in work and risk then try a trunk build (pre 2.0). 
2. close this bug incomplete, test when SM 2.0 comes out, reopen bug if needed.

Comment 4

[Sune Mølgaard]

Switched to building from trunk, which seems much better in this regard :-)