Opened 4 years ago

Closed 4 years ago

#1403 closed defect (fixed)

in a 32-bit lisp, random apparently returns bad bignums

Reported by: rme Owned by:
Priority: normal Milestone:
Component: Compiler Version: trunk
Keywords: Cc:

Description

    (defparameter *rnd-state* (make-random-state t))

    (dotimes (i 300000)
      (let* ((rand-val (random #.(1- (expt 2 64)) *rnd-state*))
             (read-val (read-from-string (with-output-to-string (o)
                                           (pprint rand-val o)))))
        (assert (= rand-val read-val)
                nil
                "rand-val: ~S, read-val: ~S" rand-val read-val)))

At some point (it may be necessary to try a few times), the assert fails and the message is:

    rand-val: 1037244565857250958, read-val: 1037244565857250958

Inspecting the variables in SLIME debuggers shows this:

#<(INTEGER 536870912) #xE65086FE5202E8E>
--------------------
Value: 1037244565857250958 = #xE65086FE5202E8E = #o71450206774510027216 = #b1110 01100101 00001000 01101111 11100101 00100000 00101110 10001110 = 1.0260616E+19
Integer-length: 64



READ-VAL:

#<(INTEGER 536870912) #xE65086FE5202E8E>
--------------------
Value: 1037244565857250958 = #xE65086FE5202E8E = #o71450206774510027216 = #b1110 01100101 00001000 01101111 11100101 00100000 00101110 10001110 = 1.0372446E+18
Integer-length: 60

I (rme) was able to duplicate this on a 32-bit ARM lisp (I haven't tested an x8632 lisp), where the message was

> Error: rand-val: 1769403817437272421, read-val: 1769403817437272421
1 > :f 0
 (76BA44C8) : 0 (%ASSERTION-FAILURE NIL (= RAND-VAL READ-VAL) "rand-val: ~S, read-val: ~S" 1769403817437272421 1769403817437272421) 452
  (SETF-PLACES-P TEST-FORM STRING &REST CONDITION-ARGS)
   SETF-PLACES-P: NIL
   TEST-FORM: (= RAND-VAL READ-VAL)
   STRING: "rand-val: ~S, read-val: ~S"
   CONDITION-ARGS: (1769403817437272421 1769403817437272421)
1 > :arg 'condition-args 0
(1769403817437272421 1769403817437272421)
1 > (mapcar 'integer-length *)
(64 61)
1 > (mapcar 'uvsize **)
(3 2)

So, that's not right: the first value appears to be a three-digit bignum.

This makes me think that we are somehow allowing non-normalized bignums to escape from the lab. I wonder if there's an error in the guts of the implementation of cl:random.

https://lists.clozure.com/pipermail/openmcl-devel/2017-January/011456.html

Change History (2)

comment:1 Changed 4 years ago by rme

Also, the 32-bit x86 lisp has been suffering from numerous test suite failures for some time now. It seems possible that this particular failure could be related to some of those failing tests.

comment:2 Changed 4 years ago by rme

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.