Summary: | www-servers/uwsgi-2.0.18 : /.../environment:line <snip>: <snip> Segmentation fault python uwsgiconfig.py --build gentoo | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | Ultrabug <ultrabug> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | sandbox, sbraz, slyfox |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=724394 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge-info.txt
emerge-history.txt environment etc.portage.tbz2 logs.tbz2 temp.tbz2 www-servers:uwsgi-2.0.18:20190311-025329.log |
Description
Toralf Förster
2019-03-11 19:42:02 UTC
Created attachment 568588 [details]
emerge-info.txt
Created attachment 568590 [details]
emerge-history.txt
Created attachment 568592 [details]
environment
Created attachment 568594 [details]
etc.portage.tbz2
Created attachment 568596 [details]
logs.tbz2
Created attachment 568598 [details]
temp.tbz2
Created attachment 568600 [details]
www-servers:uwsgi-2.0.18:20190311-025329.log
Works with sys-apps/sandbox 2.14 but not 2.15. Looks like this is the only commit between them: https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=f3e51a930312422cc78b693a247b7c5704ac90a2 Reproduced locally. I'll have a look and get a backtrace. Trigger: uwsgi does something very unusual: it runs execve() syscall from a separate thread similar to vfork() but done manually(?) via clone() without CLONE_VM|CLONE_THREAD. A few examples from strace are: 8810 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fba46f66a10) = 8827 8827 execve("/bin/sh", ["/bin/sh", "-c", "pcre-config --libs"], 0x7ffdb82b33b0 /* 36 vars */ <unfinished ...> 8827 <... execve resumed>) = 0 8827 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f93dd430850) = 8828 8828 execve("/usr/bin/uname", ["uname", "-s"], 0x560a14ae7bc0 /* 36 vars */) = 0 Breakage mechanics: Lack of CLONE_VM will introduce loads/stores of 'environ' global variable in sandbox's execvp() (I think) wrapper. Lack of CLONE_THREAD allows you to run execv*() syscalls in standalone threads sharing address space. I don't know if uwsgi explicitly imposes a limitation on mutation of global state. The setup looks very fragile. But not unreasonable. Possible plan for a fix: On linux we can work it around in sandbox by emulating execvp(ARGS) via execvpe(ARGS, <sandbox_srafter_env>). execvpe() is non-standard (available on _GNU_SOURCE) Workarounds: Build single-threaded (equivalent of MAKEOPTS=-j1) or disable sandbox in uwsgi ebuild. *** Bug 690450 has been marked as a duplicate of this bug. *** can't reproduce with sys-apps/sandbox-2.18 so maybe sandbox fixed things too... and no user reported any error, closing unless it comes back nevertheless I want to both apologize and salute the impressive debug slyfox if this one comes back, I'll know what to do thanks to you! |