MozillaZine

2.53 memory leaks

User Help for Seamonkey and Mozilla Suite
frg
 
Posts: 969
Joined: December 15th, 2015, 1:20 pm

Post Posted August 8th, 2020, 4:19 pm

> Seems web workers may be the source of the leak,

Not bad 3GB. I don't want to see this code. Bloat strikes again it seems :)

dom workers linger for some time but eventually go away. If you enabled service workers via pref this still needs fixes.

therube

User avatar
 
Posts: 20515
Joined: March 10th, 2004, 9:59 pm
Location: Maryland USA

Post Posted August 8th, 2020, 7:02 pm

jwq wrote:In my case, memory usage starts at around 2.0 GB real and 0 GB VM compressed.

Something wrong there, I'd say.
Certainly not in a new, clean Profile, opening to about:blank.

Rather possible if you're opening from Session Restore, restoring multiple tabs/windows, loading content from who knows where...

The VM compressed rises with usage and when it exceeds aroung 3.0 GB (i.e. total memory usage exceeds 5.0 GB) then I start to see lag & beachballs.

On my end, as RAM usage rises, regardless of x64, UX deteriorates.
How much RAM, & where you start experiencing issues may vary, but they'll hit you.
In all browsers.
(FF Quantum will usually go longer without negatively affecting you, compared to SeaMonkey.
So if I'm visiting "trash" sites, I may drop down to FF to do so.)
(Ate breakfast the morning, & when I came back, FF had eaten 42 GB of RAM. That was NOT a pleasant experience. Surprised that I [eventually] gained enough control to Quit out cleanly [rather then having to kill it outright] [& it took a LONG time before it finally exited memory & a while after that before my [overall] system started acting fairly normally. [16 GB physical RAM.])

There are sufficient reports of high memory consumption affecting performance on 2.53 to consider this a widespread problem affecting a large number of users. I believe that there is a problem with 2.53 which needs to be fixed.

Let me fix that...

There are sufficient reports of high memory consumption affecting performance [pick whatever application you want to, & enter, here] to consider this a widespread problem affecting a large number of users. I believe that there is a problem with [pick the application you want to, & enter, here] which needs to be fixed.

Yes, memory leaks, yes memory hog... easy to say.
Much harder to quantify in a meaningful, repeatable way, that actually points out an actual bug, that can be fixed.


So if you open your browser, cleanly, & it's using 2 GB of RAM, yes that is an issue - but that is your issue, not a general application issue affecting >2.


What's relevant is the fact that with version 2.53 the memory footprint increases with use until becomes unusable, when it was fine with version 2.49.

Now we might be kind of getting somewhere.

So... if you make a copy of your 2.53 Profile, complete, as is, 2 GB & all, & open that Profile, complete, as is, in an instance of 2.49 (try that in FF Quantum without jumping through hoops ;-)) [& even that may not be "kosher" - except for testing purposes], are you going to tell me that what opens as 2 GB in 2.53, opens at a rather svelte 300-400 MB in 2.49?

(And let me answer that. No, that will not be the case. They will both open using similar amounts of RAM, ~2 GB. Differences, yes, but not 400 in one & 2 GB in the other. And if that were the case, then you can say, ah, something isn't working correctly here. Then, you have to figure out what. Like is it an extension that is the cause [as pointed out earlier] or is there an actual issue in 2.53... or?)


Oh, & lets not forget that everything in x64 is bigger compared to the same in x86 (if you were using x86 2.49 vs x64 2.53).


Yes. The memory footprint increases with usage.

And shouldn't it?
Saying it went from 2 GB to 3 GB is a rather meaningless statement.
If you opened it, did nothing further (like I went & ate breakfast) & it ate RAM (42 GB in the case of FF for me), then I might be able to shout out - FF is a RAM pig (well, at 42 GB, I'd say yes it is) - but, but was there a fault with FF? Maybe, but I don't know? Or was it some page I happened to have open, or an extension, or some combination that caused this chewing of the fat issue? I've never seen 42 GB - before - anywhere. Surprised FF didn't actually crash. I would have expected a crash in it (or in SeaMonkey - almost assuredly in SeaMonkey - given equal circumstances). So best I can say is, "something happened" (trump is good at saying stuff like that). I can shout "42 GB" all I want, & as impressive as it sounds, it is meaningless.
Fire 750, bring back 250.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript

-Px-

User avatar
 
Posts: 443
Joined: April 20th, 2011, 1:56 am

Post Posted August 9th, 2020, 2:47 am

frg wrote:dom workers linger for some time but eventually go away.

I left the browser idle for an hour, they didn't go away
frg wrote:If you enabled service workers via pref this still needs fixes.

I didn't, this is on mostly unmodified profile

Checked current Firefox on the same site, it doesn't have that worker at all, and no such big memory usage observed...

UPD: "I left the browser idle for an hour, they didn't go away"
After testing Firefox I've pressed Measure in SM one more time, and that worker finally gone

4td8s
 
Posts: 701
Joined: June 24th, 2009, 1:07 pm

Post Posted August 11th, 2020, 9:09 am

I wonder if the RAM leaks are exclusive just to the SM 2.53.x releases
I don't seem to have the problem with SM 2.49.x and unofficial SM 2.57a1pre builds from wg9s

therube

User avatar
 
Posts: 20515
Joined: March 10th, 2004, 9:59 pm
Location: Maryland USA

Post Posted August 11th, 2020, 9:49 am

So your lone comment in this thread:
ah but I'm using uBlock origin legacy on SM 2.53.x and I'm still getting those RAM leaks no matter what
but at least TPR75's tip is very useful

viewtopic.php?p=14866582#p14866582

And now we're up to a conspiracy theory of 2.53 being rubbish. That's grand.


And the only substantive comment in the entire thread, is what Px wrote.
(Granted, you don't know how to read the memory reports. I don't either. Much less if anything there is meaningful. Anyhow, continuing to spout hot air, this post included, is just that.)
Fire 750, bring back 250.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript

Frank Lion

User avatar
 
Posts: 20791
Joined: April 23rd, 2004, 6:59 pm
Location: ... The Exorcist....United Kingdom

Post Posted August 12th, 2020, 6:45 am

therube wrote:Anyhow, continuing to spout hot air, this post included, is just that.)

Yep, internet forums are just a microcosm of real life.
Metal Lion latest SeaMonkey & Thunderbird Themes - Sea Monkey and Silver Sea Monkey
"The only thing necessary for the triumph of evil, is for good men to do nothing." - Edmund Burke (attrib.)

ndebord

User avatar
 
Posts: 875
Joined: December 7th, 2002, 9:53 am

Post Posted August 12th, 2020, 2:44 pm

Just to add a little investigation:
470,000 meg Firefox portable (32 bit 68.11)
390,000 meg Palemoon Portable (32 bit 28.11)
287,000 meg SeaMonkey Portable (32 bit 2.53.3)

Nick
-N- Quis custodiet ipsos custodes
SeaMonkey, Acer Spin, Windows 10 Pro (X64 v1909), WinPatrol, MalwarebytesPremium & PandaDome

-Px-

User avatar
 
Posts: 443
Joined: April 20th, 2011, 1:56 am

Post Posted August 13th, 2020, 12:25 am

/* Cough */
Code: Select all
18,184.00 MB (100.0%) -- explicit
├──14,689.59 MB (80.78%) -- workers
│  ├──14,615.14 MB (80.37%) -- workers(paperspace.com)
│  │  ├──12,724.63 MB (69.98%) -- worker(https://console.paperspace.com/DecoderWorker.js, 0x1fc8e118800)
│  │  │  ├──12,723.35 MB (69.97%) -- zone(0x1fca1bf6000)
│  │  │  │  ├──12,723.11 MB (69.97%) -- compartment(web-worker)
│  │  │  │  │  ├──12,723.08 MB (69.97%) -- classes
│  │  │  │  │  │  ├──12,722.30 MB (69.96%) -- class(ArrayBuffer)/objects
│  │  │  │  │  │  │  ├──12,210.19 MB (67.15%) ── malloc-heap/elements/normal
│  │  │  │  │  │  │  ├─────512.00 MB (02.82%) ── non-heap/elements/wasm
│  │  │  │  │  │  │  └───────0.11 MB (00.00%) ── gc-heap
│  │  │  │  │  │  └───────0.78 MB (00.00%) ++ (5 tiny)
│  │  │  │  │  └───────0.03 MB (00.00%) ++ (3 tiny)
│  │  │  │  └───────0.24 MB (00.00%) ++ (7 tiny)
│  │  │  └───────1.28 MB (00.01%) ++ (3 tiny)
│  │  ├─────679.68 MB (03.74%) -- worker(https://console.paperspace.com/DecoderWorker.js, 0x1fcec9be000)
│  │  │     ├──678.40 MB (03.73%) -- zone(0x1fcd9d60000)
│  │  │     │  ├──678.17 MB (03.73%) -- compartment(web-worker)
│  │  │     │  │  ├──678.13 MB (03.73%) -- classes
│  │  │     │  │  │  ├──677.38 MB (03.73%) -- class(ArrayBuffer)/objects
│  │  │     │  │  │  │  ├──512.00 MB (02.82%) ── non-heap/elements/wasm
│  │  │     │  │  │  │  └──165.38 MB (00.91%) ++ (2 tiny)
│  │  │     │  │  │  └────0.75 MB (00.00%) ++ (4 tiny)
│  │  │     │  │  └────0.04 MB (00.00%) ++ (3 tiny)
│  │  │     │  └────0.24 MB (00.00%) ++ (7 tiny)
│  │  │     └────1.28 MB (00.01%) ++ (3 tiny)
│  │  ├─────514.60 MB (02.83%) -- worker(https://console.paperspace.com/DecoderWorker.js, 0x1fca09d6000)
│  │  │     ├──513.32 MB (02.82%) -- zone(0x1fcb6b28000)
│  │  │     │  ├──513.05 MB (02.82%) -- compartment(web-worker)
│  │  │     │  │  ├──513.02 MB (02.82%) -- classes
│  │  │     │  │  │  ├──512.13 MB (02.82%) -- class(ArrayBuffer)/objects
│  │  │     │  │  │  │  ├──512.00 MB (02.82%) ── non-heap/elements/wasm
│  │  │     │  │  │  │  └────0.13 MB (00.00%) ++ (2 tiny)
│  │  │     │  │  │  └────0.89 MB (00.00%) ++ (3 tiny)
│  │  │     │  │  └────0.03 MB (00.00%) ++ (3 tiny)
│  │  │     │  └────0.27 MB (00.00%) ++ (7 tiny)
│  │  │     └────1.28 MB (00.01%) ++ (3 tiny)
│  │  ├─────514.60 MB (02.83%) -- worker(https://console.paperspace.com/DecoderWorker.js, 0x1fcbf093800)
│  │  │     ├──513.32 MB (02.82%) -- zone(0x1fcfcd15000)
│  │  │     │  ├──513.05 MB (02.82%) -- compartment(web-worker)
│  │  │     │  │  ├──513.02 MB (02.82%) -- classes
│  │  │     │  │  │  ├──512.13 MB (02.82%) -- class(ArrayBuffer)/objects
│  │  │     │  │  │  │  ├──512.00 MB (02.82%) ── non-heap/elements/wasm
│  │  │     │  │  │  │  └────0.13 MB (00.00%) ++ (2 tiny)
│  │  │     │  │  │  └────0.89 MB (00.00%) ++ (3 tiny)
│  │  │     │  │  └────0.03 MB (00.00%) ++ (3 tiny)
│  │  │     │  └────0.27 MB (00.00%) ++ (7 tiny)
│  │  │     └────1.28 MB (00.01%) ++ (3 tiny)
│  │  └─────181.63 MB (01.00%) ++ (10 tiny)
│  └──────74.45 MB (00.41%) ++ (4 tiny)

/* Cough */ :roll: :D

ndebord

User avatar
 
Posts: 875
Joined: December 7th, 2002, 9:53 am

Post Posted August 13th, 2020, 4:50 am

Px

So, you use 514.60 megs at
https://console.paperspace.com
My reading with System Explorer is 352,16 meg (no other tabs or windows open, which is not my normal usage. I average around 5 tabs open and try not to use windows at all)
-N- Quis custodiet ipsos custodes
SeaMonkey, Acer Spin, Windows 10 Pro (X64 v1909), WinPatrol, MalwarebytesPremium & PandaDome

frg
 
Posts: 969
Joined: December 15th, 2015, 1:20 pm

Post Posted August 13th, 2020, 8:41 am

Just noticed:

512.00 MB (02.82%) ── non-heap/elements/wasm

Set javascript.options.wasm to false and see how it goes.

wasm is bleeding edge work in progress and was/is probably barely usable in 56 to 60 times. 2.49 not affected because it didn't have it. We didn't backport much here yet.

FRG

Peter Creasey

User avatar
 
Posts: 747
Joined: October 26th, 2007, 2:32 pm
Location: Texas

Post Posted August 13th, 2020, 1:23 pm

frg wrote:Set javascript.options.wasm to false


Are these instructions for everyone as a measure to hold down the memory build up?

Is it safe for a very basic user to do it?

Thanks.
. . . . . . . . . . Pete

frg
 
Posts: 969
Joined: December 15th, 2015, 1:20 pm

Post Posted August 13th, 2020, 3:46 pm

> Are these instructions for everyone as a measure to hold down the memory build up?

It is very unlikely that this is the cause for all the reported issues. wasm use is not in use widespread and the sites where I tested where either completely broken or it did work for me.

> Is it safe for a very basic user to do it?

Yes. Noticed that I had set it to false for some time. Wasm is probably something malware authors will like very much now that java in the browser is gone.

FRG

Peter Creasey

User avatar
 
Posts: 747
Joined: October 26th, 2007, 2:32 pm
Location: Texas

Post Posted August 13th, 2020, 4:55 pm

frg wrote: Set javascript.options.wasm to false

> Are these instructions for everyone as a measure to hold down the memory build up?

It is very unlikely that this is the cause for all the reported issues. wasm use is not in use widespread and the sites where I tested where either completely broken or it did work for me.


Thanks. Okay, it sounds like this approach is a non-starter for us basic users.
. . . . . . . . . . Pete

webmoebius
 
Posts: 253
Joined: January 21st, 2007, 12:52 pm

Post Posted August 13th, 2020, 11:36 pm

I've recently found that increasing the parameter in about.config:

javascript.options.mem.gc_allocation_threshold_mb

from its default 30 MB size to 96 MB or even 128 MB on Windows has decreased SM memory usage drastically. As I have just made this adjustment very recently, I'm still in the process of testing what difference it will make to SM memory and resource leakages over the next while. I have both SM 2.53-64 and 2.49.5-32 running on different Windows versions and on the latter version it has made a huge difference though interestingly more CPU utilization at times can occur on the multi-core processor it is running on. I've made the same adjustments to Firefox-ESR 32 and 64 bit releases of current and older versions and will also observe whether it reduces RAM consumption as shown in Windows task manager.

-Px-

User avatar
 
Posts: 443
Joined: April 20th, 2011, 1:56 am

Post Posted August 14th, 2020, 12:55 am

frg wrote:Just noticed:

512.00 MB (02.82%) ── non-heap/elements/wasm

Set javascript.options.wasm to false and see how it goes.

wasm is bleeding edge work in progress and was/is probably barely usable in 56 to 60 times. 2.49 not affected because it didn't have it. We didn't backport much here yet.

FRG

Unfortunately, didn't help at all, and broke the site actually, reverted it back. With wasm false
Code: Select all
2,407.27 MB (100.0%) -- explicit
├────552.98 MB (22.97%) -- workers
│    ├──550.44 MB (22.87%) -- workers(paperspace.com)
│    │  ├──514.18 MB (21.36%) -- worker(https://console.paperspace.com/DecoderWorker.js, 0x1fca1d5f000)
│    │  │  ├──512.91 MB (21.31%) -- zone(0x1fd24d7a000)
│    │  │  │  ├──512.64 MB (21.30%) -- compartment(web-worker)
│    │  │  │  │  ├──512.61 MB (21.29%) -- classes
│    │  │  │  │  │  ├──512.30 MB (21.28%) -- class(ArrayBuffer)/objects
│    │  │  │  │  │  │  ├──512.30 MB (21.28%) ── malloc-heap/elements/normal
│    │  │  │  │  │  │  └────0.00 MB (00.00%) ── gc-heap
│    │  │  │  │  │  └────0.31 MB (00.01%) ++ (3 tiny)
│    │  │  │  │  └────0.03 MB (00.00%) ++ (2 tiny)
│    │  │  │  └────0.27 MB (00.01%) ++ (7 tiny)
│    │  │  └────1.27 MB (00.05%) ++ (3 tiny)
│    │  ├───34.54 MB (01.43%) -- worker(https://console.paperspace.com/audioWorker.js, 0x1fc9fa9c800)
│    │  │   ├──33.08 MB (01.37%) -- zone(0x1fd14ca6000)
│    │  │   │  ├──32.77 MB (01.36%) -- compartment(web-worker)
│    │  │   │  │  ├──32.68 MB (01.36%) -- classes
│    │  │   │  │  │  ├──32.00 MB (01.33%) -- class(ArrayBuffer)/objects
│    │  │   │  │  │  │  ├──32.00 MB (01.33%) ── non-heap/elements/wasm
│    │  │   │  │  │  │  └───0.00 MB (00.00%) ── gc-heap
│    │  │   │  │  │  └───0.68 MB (00.03%) ++ (4 tiny)
│    │  │   │  │  └───0.09 MB (00.00%) ++ (4 tiny)
│    │  │   │  └───0.31 MB (00.01%) ++ (8 tiny)
│    │  │   └───1.46 MB (00.06%) ++ (3 tiny)
│    │  └────1.72 MB (00.07%) ++ worker(https://console.paperspace.com/fileUploadWorker.js, 0x1fc9fa9f000)
│    └────2.54 MB (00.11%) ++ workers(chrome)/worker(resource://gre/modules/osfile/osfile_async_worker.js, 0x1fcb1f6f000)

Return to SeaMonkey Support


Who is online

Users browsing this forum: No registered users and 4 guests