Emerging any package runs out of memory. Probably in the checking for file collisions. Reproducible: Always Steps to Reproduce: 1. Run emerge AnyPackage 2. Will not complete - runs out of memory Actual Results: >>> Done. * checking 35 files for package collisions >>> Merging dev-libs/lzo-2.03 to / Traceback (most recent call last): File "/usr/bin/emerge", line 9277, in <module> retval = emerge_main() File "/usr/bin/emerge", line 9271, in emerge_main myopts, myaction, myfiles, spinner) File "/usr/bin/emerge", line 8687, in action_build retval = mergetask.merge(pkglist, favorites, mtimedb) File "/usr/bin/emerge", line 5937, in merge return self._merge(mylist, favorites, mtimedb) File "/usr/bin/emerge", line 6218, in _merge blockers=self._find_blockers(pkg)) File "/usr/lib64/portage/pym/portage.py", line 5597, in merge mydbapi=mydbapi, prev_mtimes=prev_mtimes) File "/usr/lib64/portage/pym/portage.py", line 10552, in merge mydbapi=mydbapi, prev_mtimes=prev_mtimes) File "/usr/lib64/portage/pym/portage.py", line 10560, in _merge cleanup=cleanup, mydbapi=mydbapi, prev_mtimes=prev_mtimes) File "/usr/lib64/portage/pym/portage.py", line 10045, in treewalk vartree=self.vartree) File "/usr/lib64/portage/pym/portage.py", line 5145, in doebuild mysettings, debug=debug, free=1, logfile=logfile) File "/usr/lib64/portage/pym/portage.py", line 3011, in spawn set_term_size(rows, columns, slave_fd) File "/usr/lib64/portage/pym/output.py", line 352, in set_term_size spawn(cmd, env=os.environ, fd_pipes={0:fd}) File "/usr/lib64/portage/pym/portage_exec.py", line 215, in spawn pid = os.fork() OSError: [Errno 12] Cannot allocate memory Expected Results: Successful emerge If I use ebuild package compile install qmerge, then it succeeds, it seems to be just emerge that is broken. I have 6G of RAM and 4G of swap space. I have a LARGE collection of installed programs. (du -sh /var/db/pkg/ claims 1.5G or 1536100) Possibly 100820 packages installed. will attach output of emerge --info
Created attachment 157427 [details] Output of emerge --info This was too large to put in a comment, so attached it.
(In reply to comment #1) > Created an attachment (id=157427) [edit] > Output of emerge --info > > This was too large to put in a comment, so attached it. That's because you enabled every last USE flag in the book. Sorry, I can't see any scenario where that would be useful. My advice is for you to either prune the USE variable to the basics you need or to get more RAM. :)
I haven't edited the use flags in weeks. Emerge only started running out of memory last week. Has something changed in how emerge handles the USE flags?
(In reply to comment #3) > I haven't edited the use flags in weeks. Emerge only started running out of > memory last week. Has something changed in how emerge handles the USE flags? There's a hint of a chance that this may be a valid question.
Bug #218378 is seems similar, but that was with listdir() rather than fork().
Created attachment 157483 [details, diff] explicitly call gc.collect() to try and free memory (In reply to comment #0) > If I use ebuild package compile install qmerge, then it succeeds, it seems to > be just emerge that is broken. > I have 6G of RAM and 4G of swap space. I have a LARGE collection of installed > programs. (du -sh /var/db/pkg/ claims 1.5G or 1536100) Possibly 100820 > packages installed. I hadn't realize how large your number of installed packages is. Do you really have 100,820 packages installed? That doesn't seem right because there fewer than 30,000 ebuilds in the portage tree. With portage-2.1.5.x you can use this command to get an exact count: portageq match / "" | wc -l Perhaps the 'Cannot allocate memory' error is legitimate. Considering that the initial dep calculation succeeded, it seems like should be enough memory though. Can you try this patch to see if it helps?
You are correct about my packages. I had tried to count the number of subdirectories under /var/db/pkg, but messed up. That command to count the packages returns 9821. Have applied the patch and it seems to have corrected the issue. Thank you for your quick and helpful response. Will I have to keep applying this patch?
I've committed the patch in svn r10717 and it will be in the next release.
This is fixed in 2.2_rc1.
