Greetings, and thank you so much for bringing this to my attention. GCL is designed to stay within physical ram, both when running as a single process and when using multiple processes when the environment GCL_MULTIPROCESS_MEMORY_POOL is set to the (local writable) directory to contain the lockfile governing the pool, as is done with the Debian package. If we are exceeding bounds and going into swap I need to look into and resolve the memory allocation failure, but in the meantime there is another environment variable which can be used as a workaround: GCL_MEM_MULTIPLE=<decimal fraction> specifies the fraction of physical ram to use. Since reproducing is questionable and build times are long, perhaps you two who have succeeded in reproducing might help a little in testing out GCL_MEM_MULTIPLE. I of course will be doing the same.
Take care, Santiago Vila <[email protected]> writes: > On Tue, May 05, 2026 at 01:41:29PM +0200, Santiago Vila wrote: > >> I did not try a second time, but it looks like the same problem, which means >> this is not really loong64-specific and maybe you can also reproduce >> the problem more easily on amd64 using the GRUB_CMDLINE_LINUX="nr_cpus=1" >> trick. > > Nevermind. Maybe this is just trying to use more memory than available. > > My single-cpu system had 16 GB of RAM and some swap. Monitoring Committed_AS > in /proc/meminfo tells me it was trying to allocate 18 GB of RAM. > > On systems with 2 CPUs, I know that it tries to allocate 27 GB of RAM. > > This is a problem not only for buildd.debian.org but also for anybody > trying to do QA. I see the package is blacklisted here: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/acl2.html > > I guess reproducible-builds people would definitely prefer not having to > blacklist it. > > Thanks. > > > -- Camm Maguire [email protected] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
