From: Alastair Bridgewater <nyef@arisu.lisphacker.com>
Date: Tue, 22 Nov 2011 15:57:55 +0000 (-0500)
Subject: debug-int: Explain why and how SB-KERNEL:MAKE-LISP-OBJ is GC-unsafe.
X-Git-Url: http://repo.macrolet.net/gitweb/?a=commitdiff_plain;h=3eb973282e2b515702c012cc2dca1dc1a9b58fb0;p=sbcl.git

debug-int: Explain why and how SB-KERNEL:MAKE-LISP-OBJ is GC-unsafe.

  * Just adding some commentary.
---

diff --git a/src/code/debug-int.lisp b/src/code/debug-int.lisp
index ac460c3..d5dd4c7 100644
--- a/src/code/debug-int.lisp
+++ b/src/code/debug-int.lisp
@@ -1973,6 +1973,18 @@ register."
 ;;; (Such values can arise in registers on machines with conservative
 ;;; GC, and might also arise in debug variable locations when
 ;;; those variables are invalid.)
+;;;
+;;; NOTE: this function is not GC-safe in the slightest when creating
+;;; a pointer to an object in dynamic space.  If a GC occurs between
+;;; the start of the call to VALID-LISP-POINTER-P and the end of
+;;; %MAKE-LISP-OBJ then the object could move before the boxed pointer
+;;; is constructed.  This can happen on CHENEYGC if an asynchronous
+;;; interrupt occurs within the window.  This can happen on GENCGC
+;;; under the same circumstances, but is more likely due to all GENCGC
+;;; platforms supporting threaded operation.  This is somewhat
+;;; mitigated on x86oids due to the conservative stack and interrupt
+;;; context "scavenging" on such platforms, but there still may be a
+;;; vulnerable window.
 (defun make-lisp-obj (val &optional (errorp t))
   (if (or
        ;; fixnum