GNU bug report logs - #37822
guile-fibers build failure

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: 37822 <at> debbugs.gnu.org
Cc: mail <at> cbaines.net
Subject: bug#37822: guile-fibers build failure
Date: Tue, 22 Oct 2019 14:39:44 +0200

Hi Chris,

Christopher Baines <mail <at> cbaines.net> skribis:

> I've now tried running the tests using Guix immediately prior to the
> recent core-updates merge (d57660c54907cc6fba8b0adf6295fd2311ada6cf),
> and immediately after the merge
> (cf3d1763ede1a329c2bc932c84591ab594bb6c96) and the tests passed before,
> and failed afterwards.
>
> I've also tried running the tests manually, I did see a couple of times
> a failure that mentioned about "Too many open files" [1].
>
> I then attempted to raise the limit for open files, I think using
> prlimit like `prlimit --nofile=8096:8096 --pid GUIX_DAEMON_PID` did the
> trick, and that meant that I built the package sucessfully.
>
> I'm thinking now that there's a relationship between the number of cores
> the tests are run with, and the required file descriptors. Also, I'm
> pretty sure this behaviour changed when core-updates was merged.

Indeed, Fibers uses ‘epoll’ and for that it consumes file descriptors
proportionally to the number of threads, IIRC.  You’d still have to have
a large number of threads to hit the default rlimit, but that’s not
impossible.

> I'll close this bug for now, as I've found a way to build the package.

To avoid “random” build failures, perhaps we should include a hack in
the ‘check’ phase, like calling ‘setrlimit’ right from there, WDYT?

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.