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