Package: scm Version: 5f3-1+b1 Severity: serious Tags: ftbfs, patch Justification: fails to build from source (but built successfully in the past)
There is a build failure affecting scm on armel, armhf and mipsel: | ;ERROR: "r4rstest.scm": integer-length: Wrong type in arg1 (0 . 0) | ; in expression: (#@string->number (#@number->string #@number)) | ; in scope: | ; (number) procedure testit | ; (testit . #@define) | ; (x) procedure float-print-test | ; (log2 slow-frexp float-precision float-print-test mult-float-print-test float-rw-range-test float-powers-of-2-test . #@define) | ; (f0.0 f0.5 f1.0 f2.0 . #@let) | ; () procedure test-inexact-printing | ; defined by load: "r4rstest.scm" | | ;STACK TRACE | 1; ((#@eqv? #@number (#@string->number (#@number->string #@number ... | 2; (#@let* ((xx (#@+ #@x (#@* #@j #@eps))) (ok? (#@testit #@xx))) ... | 3; (#@do ((j -100 (#@+ #@j 1))) ((#@or (#@not #@all-ok?) (#@> #@j ... | 4; (#@define ((log2 (#@let ((l2 (#@log 2))) (#@lambda (x) (/ (lo ... | 5; (#@let ((have-inexacts? (#@and (#@string->number "0.0") (#@ine ... | ... | | ; program args: ("./scm" "-fr4rstest.scm" "-e(test-sc4)(test-cont)(test-delay)(gc)" "-e" "(or (null? errs) (quit 1))") | make[1]: *** [Makefile:559: check] Error 1 <https://buildd.debian.org/status/fetch.php?pkg=scm&arch=armhf&ver=5f3-1&stamp=1651073592&raw=0> I've tried to debug it and it's some sort of Heisenbug. The bug is triggered by the buildds because they run with stdout redirected to a file and stdin redirected from /dev/null. I think that this changes the allocation patterns of the program slightly and exposes the bug. There is a recent change in scm that adds the bigrec() function for recycling bignums, i.e. freeing them without waiting for the gc to do it. I believe that some use of this function is the source of the bug. Note that the assertion error says "Wrong type in arg1 (0 . 0)", which is the object after bigrecy() has modified it. I tried changing "CAR(bgnm) = INUM0;" to "CAR(bgnm) = MAKINUM(42);" and the error then changed to "Wrong type in arg1 (42 . 0)", which suggests that bigrecy() was run on a reachable bignum. I haven't managed to figure out exactly which call to bigrecy() is causing the problem, so here's a patch to just disable it altogether. The bigrecy() function is a performance hack, so disabling it shouldn't cause any problems. diff --git a/scl.c b/scl.c index a572557..8d8026c 100644 --- a/scl.c +++ b/scl.c @@ -133,12 +133,14 @@ void strrecy(str) void bigrecy(bgnm) SCM bgnm; { +#if 0 if (IMP(bgnm) || !BIGP(bgnm)) return; DEFER_INTS; must_free(CHARS(bgnm), (sizet)NUMDIGS(bgnm)*sizeof(BIGDIG)); CAR(bgnm) = INUM0; CDR(bgnm) = INUM0; ALLOW_INTS; +#endif } /* can convert to string accurately with bignums */