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

Previous Next

Full log

Message #16 received at 37822 <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 37822 <at> debbugs.gnu.org
Subject: Re: bug#37822: guile-fibers build failure
Date: Tue, 22 Oct 2019 22:57:04 +0100

[Message part 1 (text/plain, inline)]

Ludovic Courtès <ludo <at> gnu.org> writes:

> 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?

If that's possible, it sounds like a good idea.

[signature.asc (application/pgp-signature, inline)]

Previous Next

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