Update of /cvsroot/sbcl/sbcl/src/compiler/hppa
In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv28971/src/compiler/hppa
Modified Files:
debug.lisp
Log Message:
1.0.7.2: fix potential GC errors due to bogus objects in backtraces
Backtrace construction involves calling MAKE-LISP-OBJ on things we
devoutly hope are tagged lisp pointers, but this is not always the
case. When we fail to detect this, and a GC follows while the bogus
object is at location visible to GC bad things will happen. (Pinning
doesn't change anything, as the object still needs to be scavenged.)
To fix this (mostly -- one can still construct bogus lisp-objects
using MAKE-LISP-OBJ, it just takes more work / is less likely to
happen by accident):
* Rename MAKE-LISP-OBJ %MAKE-LISP-OBJ, and MAKE-VALID-LISP-OBJ
MAKE-LISP-OBJ.
* Add an optional ERRORP argument to the former MAKE-VALID-LISP-OBJ,
defaulting to T.
* Always use the function formerly known as MAKE-VALID-LISP-OBJ,
passing in errorp=NIL when in doubt.
* Improve the validation done on x86/x86-64: factor out the checking
logic in possibly_valid_dynamic_space_pointer, and use it to
implment valid_lisp_ponter_p. Could be done on other platforms as
well, but better done by someone who can test the results...
Adjust other code to suit:
* MAP-ALLOCATED-OBJECTS uses %MAKE-LISP-OBJ for now, as the new
MAKE-LISP-OBJ is too slow to use for groveling over the whole
heap. (Though it does detect a bunch of bogus objects we're
constructing in ROOM now, so the time would not be really
wasted...)
No test cases because I've been unable to construct one that calls
MAKE-LISP-OBJ with bogus arguments while backtracing, but such
backtraces have been seen in the wild.
Index: debug.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/compiler/hppa/debug.lisp,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- debug.lisp 14 Jul 2005 18:48:31 -0000 1.2
+++ debug.lisp 28 Jun 2007 14:24:49 -0000 1.3
@@ -92,9 +92,9 @@
(:translate fun-code-header)
(:variant fun-pointer-lowtag))
-(define-vop (make-lisp-obj)
+(define-vop (%make-lisp-obj)
(:policy :fast-safe)
- (:translate make-lisp-obj)
+ (:translate %make-lisp-obj)
(:args (value :scs (unsigned-reg) :target result))
(:arg-types unsigned-num)
(:results (result :scs (descriptor-reg)))

Update of /cvsroot/sbcl/sbcl/src/compiler/mips
In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv28971/src/compiler/mips
Modified Files:
debug.lisp
Log Message:
1.0.7.2: fix potential GC errors due to bogus objects in backtraces
Backtrace construction involves calling MAKE-LISP-OBJ on things we
devoutly hope are tagged lisp pointers, but this is not always the
case. When we fail to detect this, and a GC follows while the bogus
object is at location visible to GC bad things will happen. (Pinning
doesn't change anything, as the object still needs to be scavenged.)
To fix this (mostly -- one can still construct bogus lisp-objects
using MAKE-LISP-OBJ, it just takes more work / is less likely to
happen by accident):
* Rename MAKE-LISP-OBJ %MAKE-LISP-OBJ, and MAKE-VALID-LISP-OBJ
MAKE-LISP-OBJ.
* Add an optional ERRORP argument to the former MAKE-VALID-LISP-OBJ,
defaulting to T.
* Always use the function formerly known as MAKE-VALID-LISP-OBJ,
passing in errorp=NIL when in doubt.
* Improve the validation done on x86/x86-64: factor out the checking
logic in possibly_valid_dynamic_space_pointer, and use it to
implment valid_lisp_ponter_p. Could be done on other platforms as
well, but better done by someone who can test the results...
Adjust other code to suit:
* MAP-ALLOCATED-OBJECTS uses %MAKE-LISP-OBJ for now, as the new
MAKE-LISP-OBJ is too slow to use for groveling over the whole
heap. (Though it does detect a bunch of bogus objects we're
constructing in ROOM now, so the time would not be really
wasted...)
No test cases because I've been unable to construct one that calls
MAKE-LISP-OBJ with bogus arguments while backtracing, but such
backtraces have been seen in the wild.
Index: debug.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/compiler/mips/debug.lisp,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- debug.lisp 13 May 2006 16:23:53 -0000 1.5
+++ debug.lisp 28 Jun 2007 14:24:49 -0000 1.6
@@ -113,9 +113,9 @@
(:translate sb!di::fun-code-header)
(:variant fun-pointer-lowtag))
-(define-vop (make-lisp-obj)
+(define-vop (%make-lisp-obj)
(:policy :fast-safe)
- (:translate sb!di::make-lisp-obj)
+ (:translate %make-lisp-obj)
(:args (value :scs (unsigned-reg) :target result))
(:arg-types unsigned-num)
(:results (result :scs (descriptor-reg)))

Update of /cvsroot/sbcl/sbcl/src/compiler/ppc
In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv28971/src/compiler/ppc
Modified Files:
debug.lisp
Log Message:
1.0.7.2: fix potential GC errors due to bogus objects in backtraces
Backtrace construction involves calling MAKE-LISP-OBJ on things we
devoutly hope are tagged lisp pointers, but this is not always the
case. When we fail to detect this, and a GC follows while the bogus
object is at location visible to GC bad things will happen. (Pinning
doesn't change anything, as the object still needs to be scavenged.)
To fix this (mostly -- one can still construct bogus lisp-objects
using MAKE-LISP-OBJ, it just takes more work / is less likely to
happen by accident):
* Rename MAKE-LISP-OBJ %MAKE-LISP-OBJ, and MAKE-VALID-LISP-OBJ
MAKE-LISP-OBJ.
* Add an optional ERRORP argument to the former MAKE-VALID-LISP-OBJ,
defaulting to T.
* Always use the function formerly known as MAKE-VALID-LISP-OBJ,
passing in errorp=NIL when in doubt.
* Improve the validation done on x86/x86-64: factor out the checking
logic in possibly_valid_dynamic_space_pointer, and use it to
implment valid_lisp_ponter_p. Could be done on other platforms as
well, but better done by someone who can test the results...
Adjust other code to suit:
* MAP-ALLOCATED-OBJECTS uses %MAKE-LISP-OBJ for now, as the new
MAKE-LISP-OBJ is too slow to use for groveling over the whole
heap. (Though it does detect a bunch of bogus objects we're
constructing in ROOM now, so the time would not be really
wasted...)
No test cases because I've been unable to construct one that calls
MAKE-LISP-OBJ with bogus arguments while backtracing, but such
backtraces have been seen in the wild.
Index: debug.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/compiler/ppc/debug.lisp,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- debug.lisp 14 Jul 2005 18:48:33 -0000 1.3
+++ debug.lisp 28 Jun 2007 14:24:49 -0000 1.4
@@ -82,9 +82,9 @@
(:translate sb!di::fun-code-header)
(:variant fun-pointer-lowtag))
-(define-vop (make-lisp-obj)
+(define-vop (%make-lisp-obj)
(:policy :fast-safe)
- (:translate sb!di::make-lisp-obj)
+ (:translate %make-lisp-obj)
(:args (value :scs (unsigned-reg) :target result))
(:arg-types unsigned-num)
(:results (result :scs (descriptor-reg)))

Update of /cvsroot/sbcl/sbcl/src/compiler/x86
In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv28971/src/compiler/x86
Modified Files:
debug.lisp
Log Message:
1.0.7.2: fix potential GC errors due to bogus objects in backtraces
Backtrace construction involves calling MAKE-LISP-OBJ on things we
devoutly hope are tagged lisp pointers, but this is not always the
case. When we fail to detect this, and a GC follows while the bogus
object is at location visible to GC bad things will happen. (Pinning
doesn't change anything, as the object still needs to be scavenged.)
To fix this (mostly -- one can still construct bogus lisp-objects
using MAKE-LISP-OBJ, it just takes more work / is less likely to
happen by accident):
* Rename MAKE-LISP-OBJ %MAKE-LISP-OBJ, and MAKE-VALID-LISP-OBJ
MAKE-LISP-OBJ.
* Add an optional ERRORP argument to the former MAKE-VALID-LISP-OBJ,
defaulting to T.
* Always use the function formerly known as MAKE-VALID-LISP-OBJ,
passing in errorp=NIL when in doubt.
* Improve the validation done on x86/x86-64: factor out the checking
logic in possibly_valid_dynamic_space_pointer, and use it to
implment valid_lisp_ponter_p. Could be done on other platforms as
well, but better done by someone who can test the results...
Adjust other code to suit:
* MAP-ALLOCATED-OBJECTS uses %MAKE-LISP-OBJ for now, as the new
MAKE-LISP-OBJ is too slow to use for groveling over the whole
heap. (Though it does detect a bunch of bogus objects we're
constructing in ROOM now, so the time would not be really
wasted...)
No test cases because I've been unable to construct one that calls
MAKE-LISP-OBJ with bogus arguments while backtracing, but such
backtraces have been seen in the wild.
Index: debug.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/compiler/x86/debug.lisp,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -d -r1.10 -r1.11
--- debug.lisp 8 Apr 2007 15:25:39 -0000 1.10
+++ debug.lisp 28 Jun 2007 14:24:49 -0000 1.11
@@ -120,9 +120,9 @@
(:translate sb!di::fun-code-header)
(:variant fun-pointer-lowtag))
-(define-vop (make-lisp-obj)
+(define-vop (%make-lisp-obj)
(:policy :fast-safe)
- (:translate sb!di::make-lisp-obj)
+ (:translate %make-lisp-obj)
(:args (value :scs (unsigned-reg unsigned-stack) :target result))
(:arg-types unsigned-num)
(:results (result :scs (descriptor-reg)

Update of /cvsroot/sbcl/sbcl/src/compiler/generic
In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv28971/src/compiler/generic
Modified Files:
vm-fndb.lisp
Log Message:
1.0.7.2: fix potential GC errors due to bogus objects in backtraces
Backtrace construction involves calling MAKE-LISP-OBJ on things we
devoutly hope are tagged lisp pointers, but this is not always the
case. When we fail to detect this, and a GC follows while the bogus
object is at location visible to GC bad things will happen. (Pinning
doesn't change anything, as the object still needs to be scavenged.)
To fix this (mostly -- one can still construct bogus lisp-objects
using MAKE-LISP-OBJ, it just takes more work / is less likely to
happen by accident):
* Rename MAKE-LISP-OBJ %MAKE-LISP-OBJ, and MAKE-VALID-LISP-OBJ
MAKE-LISP-OBJ.
* Add an optional ERRORP argument to the former MAKE-VALID-LISP-OBJ,
defaulting to T.
* Always use the function formerly known as MAKE-VALID-LISP-OBJ,
passing in errorp=NIL when in doubt.
* Improve the validation done on x86/x86-64: factor out the checking
logic in possibly_valid_dynamic_space_pointer, and use it to
implment valid_lisp_ponter_p. Could be done on other platforms as
well, but better done by someone who can test the results...
Adjust other code to suit:
* MAP-ALLOCATED-OBJECTS uses %MAKE-LISP-OBJ for now, as the new
MAKE-LISP-OBJ is too slow to use for groveling over the whole
heap. (Though it does detect a bunch of bogus objects we're
constructing in ROOM now, so the time would not be really
wasted...)
No test cases because I've been unable to construct one that calls
MAKE-LISP-OBJ with bogus arguments while backtracing, but such
backtraces have been seen in the wild.
Index: vm-fndb.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/compiler/generic/vm-fndb.lisp,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -d -r1.43 -r1.44
--- vm-fndb.lisp 7 May 2007 00:42:38 -0000 1.43
+++ vm-fndb.lisp 28 Jun 2007 14:24:49 -0000 1.44
@@ -252,7 +252,7 @@
(defknown %set-stack-ref (system-area-pointer index t) t (unsafe))
(defknown lra-code-header (t) t (movable flushable))
(defknown fun-code-header (t) t (movable flushable))
-(defknown make-lisp-obj (sb!vm:word) t (movable flushable))
+(defknown %make-lisp-obj (sb!vm:word) t (movable flushable))
(defknown get-lisp-obj-address (t) sb!vm:word (movable flushable))
(defknown fun-word-offset (function) index (movable flushable))

Update of /cvsroot/sbcl/sbcl/src/compiler/alpha
In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv28971/src/compiler/alpha
Modified Files:
debug.lisp
Log Message:
1.0.7.2: fix potential GC errors due to bogus objects in backtraces
Backtrace construction involves calling MAKE-LISP-OBJ on things we
devoutly hope are tagged lisp pointers, but this is not always the
case. When we fail to detect this, and a GC follows while the bogus
object is at location visible to GC bad things will happen. (Pinning
doesn't change anything, as the object still needs to be scavenged.)
To fix this (mostly -- one can still construct bogus lisp-objects
using MAKE-LISP-OBJ, it just takes more work / is less likely to
happen by accident):
* Rename MAKE-LISP-OBJ %MAKE-LISP-OBJ, and MAKE-VALID-LISP-OBJ
MAKE-LISP-OBJ.
* Add an optional ERRORP argument to the former MAKE-VALID-LISP-OBJ,
defaulting to T.
* Always use the function formerly known as MAKE-VALID-LISP-OBJ,
passing in errorp=NIL when in doubt.
* Improve the validation done on x86/x86-64: factor out the checking
logic in possibly_valid_dynamic_space_pointer, and use it to
implment valid_lisp_ponter_p. Could be done on other platforms as
well, but better done by someone who can test the results...
Adjust other code to suit:
* MAP-ALLOCATED-OBJECTS uses %MAKE-LISP-OBJ for now, as the new
MAKE-LISP-OBJ is too slow to use for groveling over the whole
heap. (Though it does detect a bunch of bogus objects we're
constructing in ROOM now, so the time would not be really
wasted...)
No test cases because I've been unable to construct one that calls
MAKE-LISP-OBJ with bogus arguments while backtracing, but such
backtraces have been seen in the wild.
Index: debug.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/compiler/alpha/debug.lisp,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- debug.lisp 14 Jul 2005 16:30:42 -0000 1.8
+++ debug.lisp 28 Jun 2007 14:24:49 -0000 1.9
@@ -110,9 +110,9 @@
(:translate fun-code-header)
(:variant fun-pointer-lowtag))
-(define-vop (make-lisp-obj)
+(define-vop (%make-lisp-obj)
(:policy :fast-safe)
- (:translate make-lisp-obj)
+ (:translate %make-lisp-obj)
(:args (value :scs (unsigned-reg) :target result))
(:arg-types unsigned-num)
(:results (result :scs (descriptor-reg)))

Update of /cvsroot/sbcl/sbcl/src/runtime
In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv28971/src/runtime
Modified Files:
gencgc.c
Log Message:
1.0.7.2: fix potential GC errors due to bogus objects in backtraces
Backtrace construction involves calling MAKE-LISP-OBJ on things we
devoutly hope are tagged lisp pointers, but this is not always the
case. When we fail to detect this, and a GC follows while the bogus
object is at location visible to GC bad things will happen. (Pinning
doesn't change anything, as the object still needs to be scavenged.)
To fix this (mostly -- one can still construct bogus lisp-objects
using MAKE-LISP-OBJ, it just takes more work / is less likely to
happen by accident):
* Rename MAKE-LISP-OBJ %MAKE-LISP-OBJ, and MAKE-VALID-LISP-OBJ
MAKE-LISP-OBJ.
* Add an optional ERRORP argument to the former MAKE-VALID-LISP-OBJ,
defaulting to T.
* Always use the function formerly known as MAKE-VALID-LISP-OBJ,
passing in errorp=NIL when in doubt.
* Improve the validation done on x86/x86-64: factor out the checking
logic in possibly_valid_dynamic_space_pointer, and use it to
implment valid_lisp_ponter_p. Could be done on other platforms as
well, but better done by someone who can test the results...
Adjust other code to suit:
* MAP-ALLOCATED-OBJECTS uses %MAKE-LISP-OBJ for now, as the new
MAKE-LISP-OBJ is too slow to use for groveling over the whole
heap. (Though it does detect a bunch of bogus objects we're
constructing in ROOM now, so the time would not be really
wasted...)
No test cases because I've been unable to construct one that calls
MAKE-LISP-OBJ with bogus arguments while backtracing, but such
backtraces have been seen in the wild.
Index: gencgc.c
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/runtime/gencgc.c,v
retrieving revision 1.116
retrieving revision 1.117
diff -u -d -r1.116 -r1.117
--- gencgc.c 20 Jun 2007 19:05:54 -0000 1.116
+++ gencgc.c 28 Jun 2007 14:24:49 -0000 1.117
@@ -2127,37 +2127,28 @@
#if defined(LISP_FEATURE_X86) || defined(LISP_FEATURE_X86_64)
-/* Is there any possibility that pointer is a valid Lisp object
- * reference, and/or something else (e.g. subroutine call return
- * address) which should prevent us from moving the referred-to thing?
- * This is called from preserve_pointers() */
+/* Helper for valid_lisp_pointer_p and
+ * possibly_valid_dynamic_space_pointer.
+ *
+ * pointer is the pointer to validate, and start_addr is the address
+ * of the enclosing object.
+ */
static int
-possibly_valid_dynamic_space_pointer(lispobj *pointer)
+looks_like_valid_lisp_pointer_p(lispobj *pointer, lispobj *start_addr)
{
- lispobj *start_addr;
-
- /* Find the object start address. */
- if ((start_addr = search_dynamic_space(pointer)) == NULL) {
- return 0;
- }
-
/* We need to allow raw pointers into Code objects for return
* addresses. This will also pick up pointers to functions in code
* objects. */
- if (widetag_of(*start_addr) == CODE_HEADER_WIDETAG) {
+ if (widetag_of(*start_addr) == CODE_HEADER_WIDETAG)
/* XXX could do some further checks here */
return 1;
- }
- /* If it's not a return address then it needs to be a valid Lisp
- * pointer. */
if (!is_lisp_pointer((lispobj)pointer)) {
return 0;
}
/* Check that the object pointed to is consistent with the pointer
- * low tag.
- */
+ * low tag. */
switch (lowtag_of((lispobj)pointer)) {
case FUN_POINTER_LOWTAG:
/* Start_addr should be the enclosing code object, or a closure
@@ -2399,6 +2390,47 @@
return 1;
}
+/* Used by the debugger to validate possibly bogus pointers before
+ * calling MAKE-LISP-OBJ on them.
+ *
+ * FIXME: We would like to make this perfect, because if the debugger
+ * constructs a reference to a bugs lisp object, and it ends up in a
+ * location scavenged by the GC all hell breaks loose.
+ *
+ * Whereas possibly_valid_dynamic_space_pointer has to be conservative
+ * and return true for all valid pointers, this could actually be eager
+ * and lie about a few pointers without bad results... but that should
+ * be reflected in the name.
+ */
+int
+valid_lisp_pointer_p(lispobj *pointer)
+{
+ lispobj *start;
+ if (((start=search_dynamic_space(pointer))!=NULL) ||
+ ((start=search_static_space(pointer))!=NULL) ||
+ ((start=search_read_only_space(pointer))!=NULL))
+ return looks_like_valid_lisp_pointer_p(pointer, start);
+ else
+ return 0;
+}
+
+/* Is there any possibility that pointer is a valid Lisp object
+ * reference, and/or something else (e.g. subroutine call return
+ * address) which should prevent us from moving the referred-to thing?
+ * This is called from preserve_pointers() */
+static int
+possibly_valid_dynamic_space_pointer(lispobj *pointer)
+{
+ lispobj *start_addr;
+
+ /* Find the object start address. */
+ if ((start_addr = search_dynamic_space(pointer)) == NULL) {
+ return 0;
+ }
+
+ return looks_like_valid_lisp_pointer_p(pointer, start_addr);
+}
+
/* Adjust large bignum and vector objects. This will adjust the
* allocated region if the size has shrunk, and move unboxed objects
* into unboxed pages. The pages are not promoted here, and the

Update of /cvsroot/sbcl/sbcl/src/compiler/x86-64
In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv28971/src/compiler/x86-64
Modified Files:
debug.lisp
Log Message:
1.0.7.2: fix potential GC errors due to bogus objects in backtraces
Backtrace construction involves calling MAKE-LISP-OBJ on things we
devoutly hope are tagged lisp pointers, but this is not always the
case. When we fail to detect this, and a GC follows while the bogus
object is at location visible to GC bad things will happen. (Pinning
doesn't change anything, as the object still needs to be scavenged.)
To fix this (mostly -- one can still construct bogus lisp-objects
using MAKE-LISP-OBJ, it just takes more work / is less likely to
happen by accident):
* Rename MAKE-LISP-OBJ %MAKE-LISP-OBJ, and MAKE-VALID-LISP-OBJ
MAKE-LISP-OBJ.
* Add an optional ERRORP argument to the former MAKE-VALID-LISP-OBJ,
defaulting to T.
* Always use the function formerly known as MAKE-VALID-LISP-OBJ,
passing in errorp=NIL when in doubt.
* Improve the validation done on x86/x86-64: factor out the checking
logic in possibly_valid_dynamic_space_pointer, and use it to
implment valid_lisp_ponter_p. Could be done on other platforms as
well, but better done by someone who can test the results...
Adjust other code to suit:
* MAP-ALLOCATED-OBJECTS uses %MAKE-LISP-OBJ for now, as the new
MAKE-LISP-OBJ is too slow to use for groveling over the whole
heap. (Though it does detect a bunch of bogus objects we're
constructing in ROOM now, so the time would not be really
wasted...)
No test cases because I've been unable to construct one that calls
MAKE-LISP-OBJ with bogus arguments while backtracing, but such
backtraces have been seen in the wild.
Index: debug.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/compiler/x86-64/debug.lisp,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- debug.lisp 14 Jul 2005 19:13:49 -0000 1.2
+++ debug.lisp 28 Jun 2007 14:24:49 -0000 1.3
@@ -120,9 +120,9 @@
(:translate sb!di::fun-code-header)
(:variant fun-pointer-lowtag))
-(define-vop (make-lisp-obj)
+(define-vop (%make-lisp-obj)
(:policy :fast-safe)
- (:translate sb!di::make-lisp-obj)
+ (:translate %make-lisp-obj)
(:args (value :scs (unsigned-reg unsigned-stack) :target result))
(:arg-types unsigned-num)
(:results (result :scs (descriptor-reg)