On Tuesday, 30 October 2018 06:30:23 GMT Håkon Alstadheim wrote:
> I'm having fun enabling "test" in FEATURES on my gentoo-desktop. One
> interesting failure, that brings to mind build failures I have had in
> the past:
> 
> Building sys-apps/mlocate-0.26-r2, I get
> 
>      43: updatedb: Very deep hierarchy                   FAILED
> (updatedb.at:261)
> 
> Trying to reproduce, as root I do "make check" in the work/mlocate-0.26/
> , and the test passes.
> 
>  43: updatedb: Very deep hierarchy                   ok
> 
> I'd really like to get to the bottom of this, as I believe it must have
> the same root-cause as issues I have had compiling large packages such
> as firefox.
> 
> Re-running both the emerge and the make check, I get the same results.
> emerge fails, make check succeeds. I made a local copy of the ebuild and
> inserted a "ulimit -a" in pre_src_test.
> 
> ulimit from root-shell:
> 
> # ulimit -a
> core file size          (blocks, -c) unlimited
> data seg size           (kbytes, -d) unlimited
> scheduling priority             (-e) 0
> file size               (blocks, -f) unlimited
> pending signals                 (-i) 59958
> max locked memory       (kbytes, -l) 16384
> max memory size         (kbytes, -m) unlimited
> open files                      (-n) 1024
> pipe size            (512 bytes, -p) 8
> POSIX message queues     (bytes, -q) 819200
> real-time priority              (-r) 0
> stack size              (kbytes, -s) 8192
> cpu time               (seconds, -t) unlimited
> max user processes              (-u) 10000
> virtual memory          (kbytes, -v) unlimited
> file locks                      (-x) unlimited
> 
> ulimit from emerge:
> >>> Source compiled.
> 
> core file size          (blocks, -c) unlimited
> data seg size           (kbytes, -d) unlimited
> scheduling priority             (-e) 0
> file size               (blocks, -f) unlimited
> pending signals                 (-i) 59958
> max locked memory       (kbytes, -l) 16384
> max memory size         (kbytes, -m) unlimited
> open files                      (-n) 1024
> pipe size            (512 bytes, -p) 8
> POSIX message queues     (bytes, -q) 819200
> real-time priority              (-r) 0
> stack size              (kbytes, -s) 9788
> cpu time               (seconds, -t) unlimited
> max user processes              (-u) 10000
> virtual memory          (kbytes, -v) unlimited
> file locks                      (-x) unlimited
> 
> >>> Test phase: sys-apps/mlocate-0.26-r2
> 
> I have plenty of space in my portage temp directory (/pt):
> 
>  # df -hT ./
> Filsystem      Type Størrelse Brukt Tilgj. Bruk% Montert på
> /dev/xvdc      ext4      163G  8,0G   147G    6% /pt
> 
> Portage temp is at /pt due to the earlier mentioned issues with firefox.
> 
> At my wits end here. Anyone ?

I have not looked or used the test FEATURES of portage, but have also noticed 
over time certain packages fail to build on machines with low RAM.  As low 
here I consider anything less than 4G.  It seems each thread is now consuming 
so much memory they cumulatively use up all RAM available and then start 
swapping endlessly until the compilation invariably fails.  Increasingly more 
and more packages have been suffering from this, the last two I noticed are 
qtwebkit and qtwebengine.

My solution has been to create a package.env file in which I specify MAKEOPTS 
limiting the number of jobs and average load for any of these packages which 
chew up all the RAM.
-- 
Regards,
Mick