dev-libs/jemalloc-4.2.0 introduced support for overcommit_memory setting via commit https://github.com/jemalloc/jemalloc/commit/c2f970c32b527660a33fa513a76d913c812dcf7c: > os_overcommits_proc(void) > { > int fd; > char buf[1]; > ssize_t nread; > > fd = open("/proc/sys/vm/overcommit_memory", O_RDONLY); > if (fd == -1) > return (false); /* Error. */ > > nread = read(fd, &buf, sizeof(buf)); > if (nread < 1) > return (false); /* Error. */ > /* > * /proc/sys/vm/overcommit_memory meanings: > * 0: Heuristic overcommit. > * 1: Always overcommit. > * 2: Never overcommit. > */ > return (buf[0] == '0' || buf[0] == '1'); > } This causes any program which links against jemalloc to hang when running sandboxed (i.e. in src_test phase), see bug 589378 and https://github.com/jemalloc/jemalloc/issues/430 Today someone posted a workaround using syscall(SYS_open...) instead of just open() which I can confirm solves the problem on Gentoo: https://github.com/jemalloc/jemalloc/issues/443#issuecomment-243402287 This raises the question why syscall() works around the problem. Maybe a bug in sys-apps/sandbox with open()?
> This raises the question why syscall() works around the problem. Maybe a bug > in sys-apps/sandbox with open()? It's explained in the jemalloc issue #443 - sandbox's open() replacement uses jemalloc's malloc() replacement which triggers some jemalloc initialization routine that should not be called at that point. I see two way to fix this: change jemalloc and similar custom memory allocators to avoid sandbox's allocations in problem areas, or change sandbox to always use the glibc malloc instead of allowing overrides from sandboxed libraries.
jemalloc upstream has now declined to do anything to workaround that issue saying it is a bootstrap issue and only affects people who hook into "open()": https://github.com/jemalloc/jemalloc/issues/443#issuecomment-245357510 Can the sandbox team please answer if this is a bug within sandbox's hooking or not? If it's not a bug we need a way to workaround that issue in ebuilds. I.e. ship jemalloc with my patch applied (I am not sure if syscall(SYS_OPEN...) instead of open() has performance impact)...
Upstream has changed its mind and committed https://github.com/jemalloc/jemalloc/commit/c443b67561891ae68d688daf5f8ce37820cdba2b I'll shortly bump dev-libs/jemalloc with this cherry-picked commit.
> commit 7565f43fc1c544625d153f510b950f9f9bf6e848 > Author: Thomas Deutschmann > Date: Tue Nov 1 16:22:38 2016 +0100 > > dev-libs/jemalloc: Patch added to fix an issue with sys-apps/sandbox > > Cherry picked commit c443b67561 [Link 1] which fixes an issue which > prevented any jemalloc-enabled application from running through > sys-apps/sandbox (typical use case is emerge with FEATURES=sandbox and > FEATURES=test). > > Cherry picked commit 3c8c3e9e9b [Link 2] which fixes a leaked file > descriptor. > > Link 1: https://github.com/jemalloc/jemalloc/commit/c443b67561891ae68d688daf5f8ce37820cdba2b > Link 2: https://github.com/jemalloc/jemalloc/commit/3c8c3e9e9b59b6e34a222816a05f0a01a68919b3 > Gentoo-Bug: https://bugs.gentoo.org/592420 > > Package-Manager: portage-2.3.2
there is 0 good reason why an allocator should be screwing with global system settings like /proc/sys/. i run a program as non-root and it does one thing, but if i run it as root, it now modifies global settings ? that's brain dead. the reason syscall() works is because the default sandbox mode is to run in process and hook C library calls. it makes things faster. however, sandbox can run in ptrace mode in which case it would catch & reject these sort of things. atm we only do it for static binaries, but that's not guaranteed to stay that way. so ignoring the open hooking issue, sandbox *should* be catching attempts to screw with /proc/sys/ and throwing a sandbox violation.
