Greetings! Santiago Vila <sanv...@unex.es> writes:
> On Wed, Mar 09, 2016 at 03:20:57PM -0500, Camm Maguire wrote: >> Greetings! While I still cannot reporduce this on barriere stretch, >> please try >> >> export GCL_MEM_MULTIPLE=0.2 >> >> before building. Unless of course dpkg-buildpackage -A sanitizes the >> environment, in which case please see if you can pass it on the command >> line. > > Hurrah! I confirm that the above variable makes the build to work again. > > [ I was using sbuild but I can always run "dpkg-buildpackage -A" by hand ] > > But there is a big paradox here. The machine on which it failed > (before setting the above variable) is a QEMU/KVM virtual machine with > 5GB of RAM and 2GB of swap. > > At the same time, I keep at least one successful build log for the > same version 5.37.3-1 when the virtual machine had only 2GB of RAM > (and the same 2GB of swap). > > So, it seems to me that if more available memory means the build is > more likely to fail because of memory problems, then there is > something fundamentally wrong in the build system. > Yes I've been mulling a solution, but perhaps you could suggest. GCL is in the process of enabling full use of today's common >2Gb memories. We probe brk at startup to get an effective maximum heap and manage accordingly. We need to allow some fraction for subprocess gcc, and perhaps some consideration for other running processes, while still allowing the full minimal-gc power to those (e.g. ACL2) who demand it. I need to come up with a sane default and then provide an escape setting for the power user. Each of the failures you reported were ENOMEM failures on fork for gcc (invoked via compile), i.e. the heap proper was handled well within the runtime determined limits. I have no idea how to bound or estimate subprocess gcc memory usage. Take care, > Thanks. > > > > -- Camm Maguire c...@maguirefamily.org ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
