[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: bnewbold
Subject: [Scm-discuss] 5f2 regression: r4rstest.scm fails on 32-bit
Date: Sat, 30 Sep 2017 22:16:41 -0700 (PDT)
User-agent: Alpine 2.20 (DEB 67 2015-01-07)


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>
;   (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"))

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).


PS, I stumbled across this while updating the Debian package for scm.

Attachment: bypass_bigrecy_32bit.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]