I think I found an SBCL bug, would somebody run this for me?

[Warren Wilkinson]

This code uses C to malloc 32 bytes of memory. Then I use system-area-ub32-copy and system-area-ub32-fill. The behavior of FILL is incorrect I think (in these tests, I think it should give the same output as the copying).

Code: Select all

(defvar *sap* (alien-funcall (extern-alien "malloc" (function system-area-pointer unsigned)) 32))

(defun zero-sap () (sb-kernel:system-area-ub32-fill 0 *sap* 0 8))
(defun print-sap () 
  (format t "~%~8,'0x ~8,'0x ~8,'0x ~8,'0x ~8,'0x ~8,'0x ~8,'0x ~8,'0x"
	  (sb-sys:sap-ref-32 *sap* 0) (sb-sys:sap-ref-32 *sap* 4) (sb-sys:sap-ref-32 *sap* 8)  (sb-sys:sap-ref-32 *sap* 12)
	  (sb-sys:sap-ref-32 *sap* 16) (sb-sys:sap-ref-32 *sap* 20) (sb-sys:sap-ref-32 *sap* 24)
	  (sb-sys:sap-ref-32 *sap* 28)))

(format t "~%UNSIGNED32 Copy...")
(let ((vector (make-array 8 :element-type '(unsigned-byte 32) :initial-element #xBADDBEEF)))
  (sb-sys:with-pinned-objects (vector)
    (sb-kernel:system-area-ub32-copy (sb-sys:vector-sap vector) 0 *sap* 0 8)
    (print-sap)
    (zero-sap)))

(format t "~%UNSIGNED32 Fill...")
(progn (sb-kernel:system-area-ub32-fill #xBADDBEEF *sap* 0 8)
       (print-sap)
       (zero-sap))

(format t "~%UNSIGNED8 Copy...")
(let ((vector (make-array 32 :element-type '(unsigned-byte 8) :initial-element #xAD)))
  (sb-sys:with-pinned-objects (vector)
    (sb-kernel:system-area-ub8-copy (sb-sys:vector-sap vector) 0 *sap* 0 32)
    (print-sap)
    (zero-sap)))

(format t "~%UNSIGNED8 Fill...")
(progn (sb-kernel:system-area-ub8-fill #xAD *sap* 0 32)
       (print-sap)
       (zero-sap))

My output is as follows on a 64 bit machine. This test case came from code that worked on a 32bit machine, but broke on the 64bit one. I think system-area-ubXX-fill is the culprit.

Code: Select all

my output on SBCL 1.0.44.gentoo-r0 on a 64 bit machine

UNSIGNED32 Copy...
BADDBEEF BADDBEEF BADDBEEF BADDBEEF BADDBEEF BADDBEEF BADDBEEF BADDBEEF
UNSIGNED32 Fill...
BADDBEEF 00000000 BADDBEEF 00000000 BADDBEEF 00000000 BADDBEEF 00000000
UNSIGNED8 Copy...
ADADADAD ADADADAD ADADADAD ADADADAD ADADADAD ADADADAD ADADADAD ADADADAD
UNSIGNED8 Fill...
000000AD 00000000 000000AD 00000000 000000AD 00000000 000000AD 00000000

[smcnamara]

SBCL 1.0.38 on Ubuntu-64bit

Code: Select all

UNSIGNED32 Copy...
BADDBEEF BADDBEEF BADDBEEF BADDBEEF BADDBEEF BADDBEEF BADDBEEF BADDBEEF
UNSIGNED32 Fill...
BADDBEEF 00000000 BADDBEEF 00000000 BADDBEEF 00000000 BADDBEEF 00000000
UNSIGNED8 Copy...
ADADADAD ADADADAD ADADADAD ADADADAD ADADADAD ADADADAD ADADADAD ADADADAD
UNSIGNED8 Fill...
000000AD 00000000 000000AD 00000000 000000AD 00000000 000000AD 00000000

[Warren Wilkinson]

It seems SBCL on x64 is byte-alignment sensitive. I've had to change my system-area-ub32-copy's over to system-area-ub8-copy to get my tests to pass. I'm running SBCL 1.0.44.gentoo-r0. Just a heads up for anybody who loves system-area-pointers as much as I do.

[Warren Wilkinson]

I got a response back from SBCL maintainters:

Reading the source (or the disassembly, which you might find more
transparent), you're supposed to pass a full word to the *-fill
functions. For instance, you could pass (* #xAD #x0101010101010101)
instead of #xAD. The ub8, ub16, etc. variants are still useful because
the code will make sure not to write past the last byte in the
destination range.

It's hard to tell whether this is an oversight, or intended: these
functions are internal and not documented. However, I find that the
current behaviour could be useful, and suggest that you replicate the
fill word yourself if that's what you need.

Paul Khuong