On Sat, Nov 30, 2013 at 10:42:54PM -0500, Eric Dorland wrote:
> Control: reassign -1 buildd.debian.org
> Control: severity -1 important
> Control: retitle -1 mips, mipsel buildds: Unable to disable core dumps
>
> As pointed out by Bastian Blank in
> <20131104203044.ga17...@mail.waldi.eu.org>:
>
> > Turns out it does fail. There seems to be a kernel bug that makes it
> > fails if anything tries to set a value of RLIM_INFINITY:
> >
> > | getrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=RLIM_INFINITY}) = 0
> > | setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=RLIM_INFINITY}) = -1
> > | EPERM (Operation not permitted)
> >
> > Workaround is to also set the hard limit to a smaller value.
>
All values equals or below 0x7ffffffe should work.
Note that this problem is being working on in the last few months, but
it involves a lot of people. The problem is an inconsistency in the
definition of RLIM64_INFINITY between kernel and userland. It has been
there for almost 7 years, but only really appeared when the prlimit64
syscall has been wired on the kernel side.
So far we have been able to agree that the problem should be fixed on
the glibc side. It has been fixed upstream, and the fix has been
backported in sid. However to get it fully fixed on the build daemons,
we also have to fix it in glibc/wheezy. An upload is currently being
prepared, then the step afterwards will be to get it installed on the
build daemons.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
