On Tue, 30 Oct 2018 13:29:59 +0100 Håkon Alstadheim wrote: > > Den 30. okt. 2018 10:01, skrev Mick: > > 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. > Memory should not be a problem here. Fails with only that one emerge > running, > succeeds if run directly as root, or with FEATURES="-sandbox -usersandbox". > > Memory is >14GB: > # vmstat > procs -----------memory---------- ---swap-- -----io---- -system-- > ------cpu----- > r b swpd free buff cache si so bi bo in cs us sy > id wa st > 3 4 28416 6904608 174112 4616144 0 0 65 266 13 4 10 > 2 84 4 0
It is possible that you hit directory loop. What lstree says on that dir? Anyway, report this to sandbox devs. Best regards, Andrew Savchenko
pgpx97Wp8nVj1.pgp
Description: PGP signature
