*PRINT-CIRCLE* crosstalk between streams
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| SBCL |
Medium
|
Unassigned |
Bug Description
In sbcl-0.8.10.48 it's possible for *PRINT-CIRCLE* references to be
mixed between streams when output operations are intermingled closely
enough (as by doing output on S2 from within (PRINT-OBJECT X S1) in the
test case below), so that e.g. the references #2# appears on a stream
with no preceding #2= on that stream to define it (because the #2= was
sent to another stream).
(cl:in-package :cl-user)
(defstruct foo index)
(defparameter *foo* (make-foo :index 4))
(defstruct bar)
(defparameter *bar* (make-bar))
(defparameter *tangle* (list *foo* *bar* *foo*))
(defmethod print-object ((foo foo) stream)
(let ((index (foo-index foo)))
(format *trace-output*
"~&-$- emitting FOO ~D, ambient *BAR*=~S~%"
index *bar*)
(format stream "[FOO ~D]" index))
foo)
(let ((tsos (make-string-
(ssos (make-string-
(let ((*print-circle* t)
(prin1 *tangle* *standard-output*))
(let ((string (get-output-
(unless (string= string "(#1=[FOO 4] #S(BAR) #1#)")
;; In sbcl-0.8.10.48 STRING was "(#1=[FOO 4] #2# #1#)".:-(
(error "oops: ~S" string)))))
It might be straightforward to fix this by turning the
*CIRCULARITY-
per-stream slots, but (1) it would probably be sort of messy faking
up the special variable binding semantics using UNWIND-PROTECT and
(2) it might be sort of a pain to test that no other bugs had been
introduced.
Changed in sbcl: | |
importance: | Undecided → Medium |
status: | New → Confirmed |