Bug#1024532: gjs allocates 237 GB of RAM during build (!)

[Santiago Vila]

El 21/11/22 a las 11:20, Simon McVittie escribió:
> When I upload it, I do my test-build in a VM with 2G of RAM, and that
> works fine. I'm using a bullseye VM containing bullseye's sbuild and
> schroot, with gjs built in a sid chroot by that copy of sbuild. This
> is intended to replicate Debian's production buildds as closely as is
> feasible to do on a laptop, because what matters for typical Debian users
> is whether the package is built successfully and correctly on the buildds.
> 
> In case there's a kernel difference, I've just tried it in a bookworm
> VM containing bookworm's sbuild and schroot, again with 2G of RAM. That
> was also successful.

The package builds fine for me, I never said otherwise, and this is not 
a FTBFS bug.

I am reporting this as an anomaly (a very big anomaly indeed).

I am well aware that the committed memory and the memory the package 
"really needs" are not the same. In my setup, I'm just taking the 
allocated memory as a conservative upper bound for the required memory, 
which works well in 99.99% of cases. For the cases where this upper 
bound is a lot bigger than the memory "really required", I have an 
"override" file, but the ideal thing would be not having to use it.

I suggest that you do this while building the package to see what happens:

while true; do grep Committed_AS: /proc/meminfo ; sleep 1; done

I guess this is called overcommitting (allocating a lot more than 
needed) and it's a problem by itself which is in general desirable to avoid:

https://lwn.net/Articles/104179/

> If there's a unit test that intentionally tries to provoke an
> out-of-memory situation to check that gjs handles that correctly, then
> that might be what's allocating so much RAM? I don't immediately see any
> such tests, though.

Maybe. I don't know.

> I think you might accidentally be measuring how much it *can* allocate
> if given the opportunity, as opposed to how much it strictly *needs*
> to allocate?

Not exactly. As explained, I am intentionally measuring the allocated 
memory as a completely safe upper bound for the required memory, and I 
am aware that they are not the same. Nevertheless, I try to report 
anomalies like this one when I find them.

Thanks.