Reported on https://new.reddit.com/r/firefox/comments/fx9tag/internal_memory_overflow_in_the_recent_updates/

Profile attached.

Hi,
I don't have the technical knowledge to confirm this issue but I'll add product and component so the team can make some research on it. Hopefully, someone with a more deep understanding of this matter can help. Feel free to route this ticket to the corresponding team.

Regards,
Jerónimo

(In reply to Jerónimo Torti from comment #3)

Hi,
I don't have the technical knowledge to confirm this issue but I'll add product and component so the team can make some research on it. Hopefully, someone with a more deep understanding of this matter can help. Feel free to route this ticket to the corresponding team.

Regards,
Jerónimo

How do i do that?

I bet this is related to this: bug 1386177

Memory allocator is unlikely to be the correct component for a memory leak.

Thank you for the report.

The memory usage in the main process doesn't look great. Do you have a lot of windows open? Maybe around 80? Because I see about that many browser.xhtml pages in your main process. I'm asking because I would like to determine if you are leaking windows or maybe you just have a lot of windows open.

The first content process looks reasonable, though this entry is a bit alarming: "2,097,141.53 MB (01.56%) ── mapped(segments=14)". I'm not sure if that's normal or not. Maybe this is similar to the issue that looks like WASM might not be unmapping stuff sometimes. That could be showing up in some kind of OS thing and causing issues, even if we're not really using it.

(In reply to master.engineer from comment #2)

Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: firefox.exe (17396) consumed 5625901056 bytes, firefox.exe (8224) consumed 4319272960 bytes, and firefox.exe (12508) consumed 2034941952 bytes.

Please file a new bug and needinfo me on it. It is confusing to have reports from different users, which likely have different causes given the ambiguous nature of the symptoms here, mixed together in a single bug. Thank you.

There's 2GB of reserved memory in every process, but wasm-runtime is zero in all of the processes. I do see a tiny amount of non-heap/code/wasm in one process. I don't know what else might be reserving 2GB of memory. This kind of feels like bug 1615988. Maybe they are related.

I'm going to mark this as a regression because the reporter thinks it may have started happening in 75.

(In reply to Andrew McCreight [:mccr8] from comment #9)

There's 2GB of reserved memory in every process, but wasm-runtime is zero in all of the processes. I do see a tiny amount of non-heap/code/wasm in one process. I don't know what else might be reserving 2GB of memory. This kind of feels like bug 1615988. Maybe they are related.

I'm going to mark this as a regression because the reporter thinks it may have started happening in 75.

That's actually 2TB of reserved memory, it's due to CFG on Windows. There's still stuff like:

134,217,727.94 MB (100.0%) -- address-space
├──132,090,314.63 MB (98.41%) ── free(segments=91026)
├────2,103,731.57 MB (01.57%) -- reserved
│    ├──2,097,141.53 MB (01.56%) ── mapped(segments=14)
│    └──────6,590.04 MB (00.00%) ── private(segments=1937)

Where we see 6GB of private reserved memory, that may or may not be wasm related.

Ah, right, I get our mega reservations confused. Maybe this is the wrong component then.

The main process also has this entry: 23,681.74 MB (00.02%) ++ commit. Maybe that's what is showing up in the 30GB of "memory usage" in the task manager? Looks like that is mostly this: 22,714.84 MB (00.02%) ── readonly(segments=93031). The main process has about 4.4GB of commit and another content process about 2GB, but those two are readwrite, not readonly.

I guess I was wrong about web assembly. Maybe...

I don't know if this is related, but the reporter filed this bug about Windows, but also commented in bug 1623768 about a Linux crash in mozilla::dom::PContentChild::SendGetFontListShmBlock. Maybe something weird is going wrong with shared memory for fonts? I don't know how that would be affecting both Linux and Windows, though...

(In reply to Andrew McCreight [:mccr8] from comment #14)

I don't know if this is related, but the reporter filed this bug about Windows, but also commented in bug 1623768 about a Linux crash in mozilla::dom::PContentChild::SendGetFontListShmBlock. Maybe something weird is going wrong with shared memory for fonts? I don't know how that would be affecting both Linux and Windows, though...

I am not experiencing this issue - this was a reddit post that I filed.

For bug 1623768, yeah - that was me.

(In reply to Andrew McCreight [:mccr8] from comment #12)

The main process also has this entry: 23,681.74 MB (00.02%) ++ commit. Maybe that's what is showing up in the 30GB of "memory usage" in the task manager? Looks like that is mostly this: 22,714.84 MB (00.02%) ── readonly(segments=93031). The main process has about 4.4GB of commit and another content process about 2GB, but those two are readwrite, not readonly.

Whatever it was definitely out of the normal process and would start consuming virtual memory after eating all 32gb making the system slow (even with 970evo plus ssd). I also have private version of the logs from back then. Like i told Yosif i'm still on 75.0 and unless something changed and i'm unaware of it, the problem doesn't occur at this present moment even though i'm essentially on the same session from were the problem occurred. Of course i've closed some windows/tabs and opened others so if i would have to guess some specific tab/window was the cause of this. Still there shouldn't be an overflow present meaning you need to find it and fix it. Also if i didn't make it clear enough Firefox specifically was the source of the memory hogging. If you went into the resource monitor you would see the actual usage..it's weird that on the "details" aka old process tab this memory usage was not reported under any of the firefox executables but on the resources it it..

(In reply to Andrew McCreight [:mccr8] from comment #7)

Thank you for the report.

The memory usage in the main process doesn't look great. Do you have a lot of windows open? Maybe around 80? Because I see about that many browser.xhtml pages in your main process. I'm asking because I would like to determine if you are leaking windows or maybe you just have a lot of windows open.

The user says that they had around 100 windows open.

master.engineer is the person who posted the report on Reddit and is experiencing the issue, and Asif Youssuff filed the bug based on the report? That wasn't clear to me when I read the report. Sorry for my confusion.

yes that is correct

My bug report is probably related (https://bugzilla.mozilla.org/show_bug.cgi?id=1615988), this system is a 16 GB linux notebook, several extensions installed in Firefox, but high RAM usage also happens with few windows open.

Wasm normally makes 6GB reservations on 64-bit systems for all its memories (the exception is systems with very low VM limits, where we make smaller reservations), one reservation per memory that is instantiated.

Hi, does this issue occurs to you in safe mode (add-ons disabled). Here is a link that can help you do that:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Also, does it also happen in the latest version of nightly. You can download it from here: https://nightly.mozilla.org/
Best,
Clara

Redirecting NI.

Hi, does this issue occurs to you in safe mode (add-ons disabled). Here is a link that can help you do that:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Also, does it also happen in the latest version of nightly. You can download it from here: https://nightly.mozilla.org/

I'll move this to Performance, but I'm not sure how actionable this is without more information about what the memory being used actually is, or some steps to reproduce the issue.

(In reply to Asif Youssuff from comment #23)

Redirecting NI.

Hi, does this issue occurs to you in safe mode (add-ons disabled). Here is a link that can help you do that:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Also, does it also happen in the latest version of nightly. You can download it from here: https://nightly.mozilla.org/

(In reply to Andrew McCreight [:mccr8] from comment #24)

I'll move this to Performance, but I'm not sure how actionable this is without more information about what the memory being used actually is, or some steps to reproduce the issue.

Well i already provided memory logs you can look at. The issue occurs when you get past LOOOTS of tabs and firefox windows, but i bookmark and start again every now and then so i can't reproduce it. I got to the point where it would crash after start, even in safe mode and disabled internet so it doesn't load anything.. ~12000tabs, 100 windows...still better than chrome BUTTTTT