X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=BUGS;h=ed32c27c9d9c604d744ef2d6445a46d5fd2e8ec6;hb=76311b98b531bbda4ec2ee4ddfa654a7885d6275;hp=0a4436afe9f4dbc9e0d291961c5e5fc5ccfe9670;hpb=0aa292df08039389cebc1c7d1f2134121b9b3fdf;p=sbcl.git diff --git a/BUGS b/BUGS index 0a4436a..ed32c27 100644 --- a/BUGS +++ b/BUGS @@ -2112,3 +2112,44 @@ WORKAROUND: (foo z) (values x))) (bar 1) => 11, should be 4. + +397: SLEEP accuracy + The more interrupts arrive the less accurate SLEEP's timing gets. + (time (sb-thread:terminate-thread + (prog1 (sb-thread:make-thread (lambda () + (loop + (princ #\!) + (force-output) + (sb-ext:gc)))) + (sleep 1)))) + +398: GC-unsafe SB-ALIEN string deporting + Translating a Lisp string to an alien string by taking a SAP to it + as done by the :DEPORT-GEN methods for C-STRING and UTF8-STRING + is not safe, since the Lisp string can move. For example the + following code will fail quickly on both cheneygc and pre-0.9.8.19 + GENCGC: + + (setf (bytes-consed-between-gcs) 4096) + (define-alien-routine "strcmp" int (s1 c-string) (s2 c-string)) + + (loop + (let ((string "hello, world")) + (assert (zerop (strcmp string string))))) + + (This will appear to work on post-0.9.8.19 GENCGC, since + the GC no longer zeroes memory immediately after releasing + it after a minor GC. Either enabling the READ_PROTECT_FREE_PAGES + #define in gencgc.c or modifying the example so that a major + GC will occasionally be triggered would unmask the bug.) + + On cheneygc the only solution would seem to be allocating some alien + memory, copying the data over, and arranging that it's freed once we + return. For GENCGC we could instead try to arrange that the string + from which the SAP is taken is always pinned. + + For some more details see comments for (define-alien-type-method + (c-string :deport-gen) ...) in host-c-call.lisp. + +399: LOOP FOR ACROSS and full call to DATA-VECTOR-REF + (fixed in sbcl-0.9.9.x)