[Scm-discuss] 5f2 regression: r4rstest.scm fails on 32-bit

[Steve VanDevender]

address@hidden writes:
 > I've had trouble getting scm 5f2 to pass r4rstests.scm on several 32-bit 
 > platforms. 5f1 works fine, and the test that fails has not changed. The 
 > failure looks like, after building vanilla sources and using default 
 > configuration (except pointing to a slightly old system-wide copy of 
 > slib):
 > 
 > ;ERROR: "r4rstest.scm": round-quotient: Wrong type in arg1 (0 . 0)
 > ; in expression: (address@hidden>string address@hidden)
 > ; in scope:
 > ;   (num)  procedure <anon>
 > ;   (estr)  procedure <anon>
 > ;   (cnt)  procedure <anon>
 > ;   (#<id loop:b75379d0> cnt)  procedure <anon>
 > [SNIP]
 > ;   (6)
 > ;   (success . address@hidden)
 > ;   ()  procedure float-rw-range-test
 > ;   (log2 slow-frexp float-precision float-print-test 
 > mult-float-print-test float-rw-range-test . address@hidden)
 > ;   (f0.0 f0.5 f1.0 f2.0)  procedure <anon>
 > ;   ()  procedure test-inexact-printing
 > ; defined by load: "r4rstest.scm"
 > 
 > A minimal test to cause this failure on a 32-bit machine is:
 > 
 >    (display (string->number "1.e15"))

This has been bugging me for a while too.  Here are some even more
precise cases down to successive integers that, when converted to real
numbers, print or do not (I also enabled one of the debugging printfs in
pdbl2str):

> (- (expt 2 49) 1)
562949953421311
> 562949953421311.
mantissa = 1 -> #x1ffffffffffff0; e2 = 49 -> -4; point = -1; ndig = 53 -> 53
5.62949953421311e14
> (expt 2 49)
562949953421312
> 562949953421312.
mantissa = 0.5 -> #x10000000000000; e2 = 50 -> -3; point = 0; ndig = 53 -> 53

;ERROR: "/home/stevev/scm/Transcen.scm": round-quotient: Wrong type in arg1 (0 
. 0)
; in scope:
;   (z1 z2)  procedure expt
; defined by load: "/home/stevev/scm/Transcen.scm"

> (+ (expt 2 54) 5)
18014398509481989
> 18014398509481989.
mantissa = 0.5 -> #x10000000000001; e2 = 55 -> 2; point = 1; ndig = 53 -> 53

;ERROR: number->string: Wrong type in arg1 (0 . 0)
; in top level environment.
> (+ (expt 2 54) 6)
18014398509481990
> 18014398509481990.
mantissa = 0.5 -> #x10000000000002; e2 = 55 -> 2; point = 1; ndig = 53 -> 53
1.801439850948199e16

 > Commenting out the body of `bigrecy()` on 32-bit platforms gets 
 > r4rstests.scm to pass, which might help with debugging (patch attached).
 > 
 > Some armchair speculation:
 > 
 > It's not a simple size problem: "1.e12", "1.e20", and "1.e300" all work 
 > fine.
 > 
 > After some debugging with gdb, my hypothesis is that there is a "use after 
 > free()"-style bug with the new `bigrecy()` optmization, which results in 
 > the 'round-quotient' call at scl.c:184 happening after `num` has somehow 
 > accidentially been "recycled" and reset to an empty pair. This failure 
 > mode doesn't happen on 64-bit machines because `num` fits as an immediate 
 > integer, instead of being a pointer to a bignum (i'm probably mangling 
 > terminology here).
 > 
 > I don't know if the problem is actually a use-after-free situation (in 
 > which case it might be lurking on 64-bit platforms) or a problem with 
 > `bigrecy()` overwriting adjacent memory locations or something (in which 
 > case it wouldn't be).
 > 
 > --bryan
 > 
 > PS, I stumbled across this while updating the Debian package for scm.
 > x[DELETED ATTACHMENT bypass_bigrecy_32bit.patch, text/x-diff]
 > _______________________________________________
 > Scm-discuss mailing list
 > address@hidden
 > https://lists.gnu.org/mailman/listinfo/scm-discuss