| Summary: | app-editors/neovim merging hangs while generating helptags | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | anoteros <anoteros> |
| Component: | Current packages | Assignee: | Vim Maintainers <vim> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bearcatsandor, christopher.paul.hanson, g2boojum, gmt, holgersson, iskatu, jstein, Letto2, mail, maksbotan, mozilla, nvinson234, pageexec |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| URL: | https://github.com/neovim/neovim/issues/4920 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
anoteros
2016-06-18 02:46:21 UTC
It seems to build find with USE="-jemalloc" hitting the same thing. I'll try the workaround. yes, confirming the workaround on my end. The issue is with libsandbox and libjemalloc. In short, when jemalloc during jemalloc initialization, jemalloc calls open("/proc/vm/overcommit_memory"). The open call is caught by sandbox. Sandbox calls dlvsym() to find the real open() function. dlvsym() calls calloc(), which is jemalloc's calloc(), and calloc(), begins executing (at least part of) jemalloc()'s initialization again. Finally, the initialization deadlocks because jemalloc was already initializing.
I'm not sure what the fix for this would be, but one idea is to re-implement dl*sym() in sandbox, so these types of problems don't occur.
Just wanted to add that Gentoo has seen this before with firefox. Here's that bug URL: https://bugzilla.mozilla.org/show_bug.cgi?id=435683 It looks like Mozilla fixed their issue by patching jemalloc. I can confirm the bug and workaround. @mozilla, maybe we should fix jemalloc in portage? The workaround I've used is to create /etc/portage/env/nosandbox like so:
FEATURES="${FEATURES} -sandbox -usersandbox"
and then activate this for affected packages, by adding lines like so to /etc/portage/package.env:
app-editors/neovim nosandbox
Perhaps, like me, some folks will find this slightly less distasteful than opting not to use jemalloc; I guess it might depend on how important paranoia is in your schedule of priorities*.
* If you are truly paranoid, you should probably not be /relying/ on the sandbox feature but using it as a failsafe. It's not even a real sandbox, unless you activate the experimental namespaces feature, and even then, it's not really designed to be an impenetrable security barrier, but more of a QA/bug-catcher mechanism.
I can confirm that Greg's fix works well. Thank you Greg! If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team still happens, reopening. workaround isn't a real fix. (In reply to Ian Stakenvicius from comment #10) > still happens, reopening. workaround isn't a real fix. Fully agreed. Indeed, "turn off jemalloc helps" is not even a diagnosis, and I see no clear evidence this has to be a bug in jemalloc .. i.e.: it could be a sandbox bug, for example, or the obvious thing: a neovim bug. USE="-jemalloc" worked for me. Looks to be long since fixed. |
