You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "AndyPang (JIRA)" <ji...@apache.org> on 2016/02/02 03:48:40 UTC
[jira] [Created] (MESOS-4577) libprocess can not run on 16-byte
aligned stack mandatory architecture(aarch64 ppc64)
AndyPang created MESOS-4577:
-------------------------------
Summary: libprocess can not run on 16-byte aligned stack mandatory architecture(aarch64 ppc64)
Key: MESOS-4577
URL: https://issues.apache.org/jira/browse/MESOS-4577
Project: Mesos
Issue Type: Bug
Components: containerization, libprocess, stout
Environment: Linux 10-175-112-202 4.1.6-rc3.aarch64 #1 SMP Mon Oct 12 01:43:03 UTC 2015 aarch64 aarch64 aarch64 GNU/Linux
Reporter: AndyPang
libprocess 3rdparty stout library(in linux.hpp) packaging a syscall "clone" :
{code:title=clone|borderStyle=solid}
inline pid_t clone(const lambda::function<int()>& func, int flags)
{
// Stack for the child.
// - unsigned long long used for best alignment.
// - 8 MiB appears to be the default for "ulimit -s" on OSX and Linux.
//
// NOTE: We need to allocate the stack dynamically. This is because
// glibc's 'clone' will modify the stack passed to it, therefore the
// stack must NOT be shared as multiple 'clone's can be invoked
// simultaneously.
int stackSize = 8 * 1024 * 1024;
unsigned long long *stack =
new unsigned long long[stackSize/sizeof(unsigned long long)];
pid_t pid = ::clone(
childMain,
&stack[stackSize/sizeof(stack[0]) - 1], // stack grows down.
flags,
(void*) &func);
// If CLONE_VM is not set, ::clone would create a process which runs in a
// separate copy of the memory space of the calling process. So we destroy the
// stack here to avoid memory leak. If CLONE_VM is set, ::clone would create a
// thread which runs in the same memory space with the calling process.
if (!(flags & CLONE_VM)) {
delete[] stack;
}
return pid;
}
{code}
syscal "clone" parameter stack is 8-byte aligned,so if in 16-byte aligned stack mandatory architecture(aarch64 ppc64) it will get error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)