Memory leak and unresponsive
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
People
(Reporter: trashforaw, Unassigned)
Details
(Keywords: dupeme)
Attachments
(4 files)
Capture.PNG
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.4
Steps to reproduce:
Does not matter. Problem seems to be related to memory usage.
Simply open 300-500 pictures in tabs.
Actual results:
-
Memory usage is increasing even when I do nothing.
Obviously a leak. -
More important
When reaching 900 MB memory the browser gets more and more slow.
At 1000 MB it becomes absolutely unresponsive and needs to be killed.
Sometimes I have to do this 5 times a day. :(
Expected results:
It just should work!
I don't understand why this has not been fixed for a long time.
I have tested Firefox 78.3 ESR and Pale Moon 28.14 in the same environment.
Both are working fine.
|
||
Comment 1•4 years ago
|
||
|
||
Comment 2•4 years ago
|
||
Well maybe it is time for a new PC. First you seem to run the 32 bit x86 version. Nothing wrong with it until you stress it. And loading 500 pictures does. Not uncommon to take 600 to 2GB and more especially when you also enable all javascript on some sites. So try the x64 first.
Without an about:memory report and if the memory goes up and up a diff nothing can be done here.
|
|
||
Comment 3•4 years ago
•
|
||
x86 a few tabs in a vm. Surprise pictures take memory away :) Still usable but the site is light with javascript. Use a google site without an ad or script blocker and it would probably be game over. If I add a few more tabs it would go down the drain fast too.
|
|
||
Comment 4•4 years ago
|
||
And here the memory report. Nothing remarkable other than needing memory.
|
Reporter | |
Comment 5•4 years ago
|
||
This is not an issue with the computer.
The problem seems to come from the memory management in the application.
I have made some tests now with these versions:
SeaMonkey 2.53.4. (32-bit) (SM)
Pale Moon 28.14.2 (32-bit) (PM)
Tested on Windows 7 Prof, x86 and x64 on the same hardware, SSD, 4 GB Ram.
Scenario: 10 Windows with ~60 open tabs, some using JS.
Problem: On x86 SM dies after 1-2 hours.
With an additional window that loads 200 pictures in tabs SM is dead immediately.
The same situation with PM works fine.
Both processes are using 2 GB address space.
PB allocates up to 1800 MB and comes back to less than 1000 MB.
Always responding.
SM does not allocate more than 1200 MB. Then it is stuck and dead.
Constant CPU load of 25 % (4 cores).
There were at least 1000 MB of free memory but it was not used.
Same tests on x64:
Both processes get 4 GB address space.
Here SM works properly similar to PM.
Allocation up to 2 GB and coming down again when everything is done.
Memory report on x86 was created just before SM died.
Ok, tell me to use x64 platform only. :(
But when I get a 32-bit application then I expect that it works properly even on a 32-bit system.
If you are not able to fix this problem then it might be a good idea to set the 32-bit version to discontinued.
With this bug it is really useless.
|
|
Reporter | |
Comment 6•4 years ago
|
||
Memory report on x86 close before lockup.
|
|
Reporter | |
Comment 7•3 years ago
|
||
I have just received a mail.
But here it seems that nothing has changed. ?
Anyway, the event queue seems to get screwed up.
Even when using only 700 MB memory.
This is really crap when the browser is dead every 15-30 minutes for no reason. :(
I have loved it for a long time due to the mail integration and the stable UI.
But now it seems to be the time to go for some of the moonchild's products.
Description
•