Rob Browning writes: > Rob Browning writes: > >> Rob Browning writes: >> >>> It looks like gc.test may be failing intermittently in Debian (see below). >>> Searching around I saw at least one other report of this in the #guile >>> logs from last year. >>> >>> For now, I'm wondering if if would be plausible to mark the test as >>> unresolved to avoid guile-2.2's removal from Debian testing, or if the >>> failure is likely to indicate a problem serious enough to warrant that >>> removal. >> >> Just wanted to check back about this. It's caused a build on the buildds >> to fail again. > > As an update, If we don't resolve this, guile-2.2 will be removed from > Debian testing this weekend. Hello Rob, The test fails with 2.2.4+1-1 on amd64 as well: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/guile-2.2.html It's really tricky to get it to fail predictably, but you can even your odds by testing only asyncs.test and gc.test: apt-get source guile-2.2 cd guile-2.2-2.2.4+1 dpkg-buildpackage -us -uc mkdir test-suite/async-tests cp test-suite/tests/{asyncs,gc}.test test-suite/async-tests/ meta/guile --debug -L $PWD/test-suite --no-auto-compile \ -e main -s $PWD/test-suite/guile-test \ --test-suite $PWD/test-suite/async-tests \ --log-file check-guile-async.log Try the last command around a dozen times and it'll fail eventually. I didn't get further with debugging than determining that something probably goes wrong in the interaction between queue_after_gc_hook(), scm_i_async_push() and scm_i_async_pop(). Every time there was a failure, this condition was false (the cdr was set to empty list): if (scm_is_false (SCM_CDR (after_gc_async_cell))) { SCM_SETCDR (after_gc_async_cell, t->pending_asyncs); t->pending_asyncs = after_gc_async_cell; } Regards, -- Göran Weinholt Debian developer 73 de SA6CJK