Created attachment 867599 [details] emerge --info When emerging dev-python/numexpr, the emerge fails with: "error: command '/usr/bin/x86_64-pc-linux-gnu-gcc' failed: Cannot allocate memory". This error does not occur if emerge is invoked with `FEATURES=-usersandbox`. To reproduce the problem outside of emerge, cd to the workdir (/var/tmp/portage/dev-python/numexpr-2.8.4/work/numexpr-2.8.4 in my case) and then run `sandbox python3.11 setup.py build_ext -j 1`. strace indicates the failed allocation is in the following syscall: [pid 9362] clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f33d3d90990) = -1 ENOMEM (Cannot allocate memory) I have attached my emerge --info and am adding supplementary attachments with build log and compressed strace log.
Created attachment 867600 [details] build log
Created attachment 867601 [details] xz-compressed strace output including clone call failing to allocate memory
I am unable to reproduce the issue.
What other information can I provide to help in reproducing the problem?
If you can provide steps to reproduce the issue from a fresh stage3, that would help. At the moment, I have no idea what unique aspect of your system triggers the issue.
My best guess is that the kernel is enforcing some limit on memory, and running the build within the sandbox is just enough to exceed that limit. I would look for any suspiciously low limits in /etc/security/limits.conf. I also wonder if you have customized these sysctl settings: vm.overcommit_memory vm.overcommit_ratio These affect the amount of memory the kernel will permit a cloned process to use. The configuration of numpy and its dependencies might also have some effect. Locally, I usually have the "lapack" USE flag on numpy disabled to minimize the dependency footprint. I tried enabling "lapack" as a test, but that had no effect. numpy[lapack] also has some dependencies that optionally depend code written in fortran. I would prefer not to rebuild them with fortran enabled unless there is some evidence that triggers the issue.
(In reply to Mike Gilbert from comment #6) > numpy[lapack] also has some dependencies that optionally depend code written > in fortran. I would prefer not to rebuild them with fortran enabled unless > there is some evidence that triggers the issue. To this end, a list of other packages which fail could be helpful.
