Le 20/11/2015 15:39, John Paul Adrian Glaubitz a écrit :
> On 11/20/2015 03:28 PM, Laurent Vivier wrote:
>>> So, from your question I assume prlimit64 is not supposed to be present
>>> in an m68k binary? I'll check what ruby does during configure.
>>
>> As the prlimit64 syscall number is defined in m68k linux includes, it is
>> defined in qemu and thus it is allowed and managed. I don't understand
>> why it doesn't work on real machine. What is the kernel version used ?
>
> root@pacman:~> uname -a
> Linux pacman 3.16.0-4-m68k #1 Debian 3.16.7-ckt4-1 (2015-01-16) m68k
> GNU/Linux
> root@pacman:~>
It should be recent enough ;)
I think prlimit() is supported by all the archs as it is defined in
linux/sys/kernel.c
But this call is strange:
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024,
rlim_max=RLIM64_INFINITY}) = 0
according to man of prlimit (if prlimit64() has the same API):
int prlimit(pid_t pid, int resource, const struct rlimit *new_limit,
struct rlimit *old_limit);
it is setting the new_limit with a NULL pointer.
RLIMIT_STACK
The maximum size of the process stack, in bytes. Upon reaching this
limit, a SIGSEGV signal is generated. To handle this signal, a process
must employ an alternate signal stack (sigaltstack(2)).
Laurent
