2.53 memory leaks

[frg]

> 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]

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.

[-Px-]

dom workers linger for some time but eventually go away.

I left the browser idle for an hour, they didn't go away

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]

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]

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

http://forums.mozillazine.org/viewtopic ... #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.)

[Frank Lion]

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

Yep, internet forums are just a microcosm of real life.

[ndebord]

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

[-Px-]

/* 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 */

[ndebord]

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)

[frg]

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]

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.

[frg]

> 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]

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.

[webmoebius]

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-]

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)