bug#37822: guile-fibers build failure
The guile-fibers package seems to fail to build on some machines.
starting phase `check'
make check-am
make[1]: Entering directory
'/tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0'
make check-TESTS
make[2]: Entering directory
'/tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0'
assert #f equal to #f: ok
assert #t terminates: ok
assert (false-if-exception (begin (run-fibers) #t)) equal to #f: ok
assert terminates: (run-fibers (lambda () (sleep 1)) #:drain? #t): ok
(1.044672258 s)
assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda ()
#t #:drain? #t): ok (0.034571671 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda ()
#t #:drain? #t): ok (0.05742899 s)
assert terminates: (run-fibers (lambda () (do-times 100 (spawn-fiber (lambda ()
#t #:drain? #t): ok (0.022090434 s)
assert terminates: (run-fibers (lambda () (do-times 1000 (spawn-fiber (lambda
() #t #:drain? #t): ok (0.110914993 s)
assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda
() #t #:drain? #t): ok (0.110751905 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda
() #t #:drain? #t): ok (0.747805854 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda
() #t) #:parallel? #t))) #:drain? #t): ok (1.116078927 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber
loop-to-1e4))) #:drain? #t): ok (396.536024374 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber
loop-to-1e4 #:parallel? #t))) #:drain? #t): ok (67.471703208 s)
assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda ()
(sleep 1) #:drain? #t): ok (1.027788168 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda ()
(sleep 1) #:drain? #t):
/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash: line
5: 2
445 Aborted
top_srcdir="/tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0" ./env
/gnu/store/1mkkv2caiqbdbbd256c4dirfi4kwsacv-guile-2.2.6/bin/guile -s ${dir}$tst
FAIL: tests/basic.scm
This is from milano-guix-1, which has 32 cores. I'm a bit confused as to
what is actually causing the test to fail. I'm guessing it could be
timing out, but I can't see anything looking at the time the test takes
to run.
For comparison, this is a successful run for the above tests.
starting phase `check'
make check-am
make[1]: Entering directory
'/tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0'
make check-TESTS
make[2]: Entering directory
'/tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0'
assert #f equal to #f: ok
assert #t terminates: ok
assert (false-if-exception (begin (run-fibers) #t)) equal to #f: ok
assert terminates: (run-fibers (lambda () (sleep 1)) #:drain? #t): ok
(1.005070844 s)
assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda ()
#t #:drain? #t): ok (0.0018557 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda ()
#t #:drain? #t): ok (0.001681844 s)
assert terminates: (run-fibers (lambda () (do-times 100 (spawn-fiber (lambda ()
#t #:drain? #t): ok (0.024649538 s)
assert terminates: (run-fibers (lambda () (do-times 1000 (spawn-fiber (lambda
() #t #:drain? #t): ok (0.004700786 s)
assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda
() #t #:drain? #t): ok (0.039034647 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda
() #t #:drain? #t): ok (0.300057354 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda
() #t) #:parallel? #t))) #:drain? #t): ok (0.324367502 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber
loop-to-1e4))) #:drain? #t): ok (149.039109838 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber
loop-to-1e4 #:parallel? #t))) #:drain? #t): ok (27.865951688 s)
assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda ()
(sleep 1) #:drain? #t): ok (1.004129529 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda ()
(sleep 1) #:drain? #t): ok (1.002370241 s)
assert terminates: (run-fibers (lambda () (do-times 100 (spawn-fiber (lambda ()
(sleep 1) #:drain? #t): ok (1.005520729 s)
assert terminates: (run-fibers (lambda () (do-times 1000 (spawn-fiber (lambda
() (sleep 1) #:drain? #t): ok (1.062105807 s)
assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda
() (sleep 1) #:drain? #t): ok (1.839309678 s)
assert terminates: (run-fibers (lambda () (do-times 2 (spawn-fiber (lambda
() (sleep 1) #:drain? #t): ok (2.814509145 s)
assert terminates: (run-fibers (lambda () (do-times 4 (spawn-fiber (lambda
() (sleep 1) #:drain? #t): ok (5.607027563 s)
assert terminates: (run-fibers (lambda () (spawn-fiber-tree 5 (lambda () (sleep
1 #:drain? #t): o
bug#37822: guile-fibers build failure
Christopher Baines writes:
> The guile-fibers package seems to fail to build on some machines.
>
> starting phase `check'
> make check-am
> make[1]: Entering directory
> '/tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0'
> make check-TESTS
> make[2]: Entering directory
> '/tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0'
> assert #f equal to #f: ok
> assert #t terminates: ok
> assert (false-if-exception (begin (run-fibers) #t)) equal to #f: ok
> assert terminates: (run-fibers (lambda () (sleep 1)) #:drain? #t): ok
> (1.044672258 s)
> assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda ()
> #t #:drain? #t): ok (0.034571671 s)
> assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda
> () #t #:drain? #t): ok (0.05742899 s)
> assert terminates: (run-fibers (lambda () (do-times 100 (spawn-fiber (lambda
> () #t #:drain? #t): ok (0.022090434 s)
> assert terminates: (run-fibers (lambda () (do-times 1000 (spawn-fiber (lambda
> () #t #:drain? #t): ok (0.110914993 s)
> assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber
> (lambda () #t #:drain? #t): ok (0.110751905 s)
> assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber
> (lambda () #t #:drain? #t): ok (0.747805854 s)
> assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber
> (lambda () #t) #:parallel? #t))) #:drain? #t): ok (1.116078927 s)
> assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber
> loop-to-1e4))) #:drain? #t): ok (396.536024374 s)
> assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber
> loop-to-1e4 #:parallel? #t))) #:drain? #t): ok (67.471703208 s)
> assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda ()
> (sleep 1) #:drain? #t): ok (1.027788168 s)
> assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda
> () (sleep 1) #:drain? #t):
> /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash: line
> 5: 2
> 445 Aborted
> top_srcdir="/tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0" ./env
> /gnu/store/1mkkv2caiqbdbbd256c4dirfi4kwsacv-guile-2.2.6/bin/guile -s
> ${dir}$tst
> FAIL: tests/basic.scm
>
>
> This is from milano-guix-1, which has 32 cores. I'm a bit confused as to
> what is actually causing the test to fail. I'm guessing it could be
> timing out, but I can't see anything looking at the time the test takes
> to run.
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.
I'll close this bug for now, as I've found a way to build the package.
1:
make check-TESTS
make[2]: Entering directory '/home/cbaines/fibers-1.0.0'
assert #f equal to #f: ok
assert #t terminates: ok
assert (false-if-exception (begin (run-fibers) #t)) equal to #f: ok
assert terminates: (run-fibers (lambda () (sleep 1)) #:drain? #t): ok
(1.065373625 s)
assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda ()
#t #:drain? #t): ok (0.099213566 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda ()
#t #:drain? #t): ok (0.25544907 s)
assert terminates: (run-fibers (lambda () (do-times 100 (spawn-fiber (lambda ()
#t #:drain? #t): ok (0.072169616 s)
assert terminates: (run-fibers (lambda () (do-times 1000 (spawn-fiber (lambda
() #t #:drain? #t): ok (0.02872572 s)
assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda
() #t #:drain? #t): ok (0.099789859 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda
() #t #:drain? #t): ok (0.560994013 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda
() #t) #:parallel? #t))) #:drain? #t): ok (0.913570257 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber
loop-to-1e4))) #:drain? #t): ok (7.429164661 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber
loop-to-1e4 #:parallel? #t))) #:drain? #t): ok (1.135422681 s)
assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda ()
(sleep 1) #:drain? #t): ok (1.020960002 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda ()
(sleep
bug#37822: guile-fibers build failure
Hi Chris, Christopher Baines 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’.
bug#37822: guile-fibers build failure
Ludovic Courtès writes: > Christopher Baines 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 Description: PGP signature
