Michael S (already5chosen.delete@this.yahoo.com) on January 20, 2020 7:45 am wrote:
> 32-bit build? Then, may be. I didn't use it for a few years.
>
> [O.T.]
> I'd like to use 32-bit FF, but on WinXP, which is not supported by Mozilla. So, I use K-Meleon
> here, which is pretty buggy, but far less resource hog then the last FF (52.0.2).
> [O.T.]

We've stripped support for Windows XP a long time ago, sorry :-)

> Yes, that's more relevant than "Free" of task manager, probably the same as "Available" in there.
> Still sounds a little pessimistic in context of allocation, but I don't know how to get a better number.
>
> Still, two numbers together make no sense. The report has to be wrong.
> Except, you said, it's 32-bit. There is a small chance that numbers are correct,
> but we have a case of helplessly fragmented process's *virtual* address space.

The crash was caused by commit space exhaustion. The "Available Page File" annotation is 0, that's commit space under a different name (historical reasons). This is an example where we still have free physical memory (though not much) but we still crash because of commit space exhaustion.

"Available Virtual Memory" is 3,4 GiB so not a problem unless it was terribly fragmented. That being said ~30% of our OOM crashes on 32-bit Windows are due to lack of virtual memory space.