diff src/alloc.c @ 4880:ae81a2c00f4f

try harder to avoid crashing when debug-printing -------------------- ChangeLog entries follow: -------------------- src/ChangeLog addition: 2010-01-18 Ben Wing <ben@xemacs.org> * lisp.h: * print.c: New variable `in_debug_print'. * alloc.c: * alloc.c (free_managed_lcrecord): If gc_in_progress and in_debug_print, just return instead of crashing. This only happens when the programmer calls debug_print() or a variation inside of a debugger, and is probably already diagnosing a crash. * print.c (struct debug_bindings): * print.c (debug_prin1_exit): * print.c (debug_prin1): At entrance, record the old value of in_debug_print in the debug_bindings, set up an unwind-protect to restore the old value, and set in_debug_print to 1. In the unwind-protect, restore the old value.
author Ben Wing <ben@xemacs.org>
date Mon, 18 Jan 2010 06:05:21 -0600
parents 5d120deb60ca
children 6ef8256a020a 714f7c9fabb1
line wrap: on
line diff
--- a/src/alloc.c	Sat Jan 16 06:50:01 2010 -0600
+++ b/src/alloc.c	Mon Jan 18 06:05:21 2010 -0600
@@ -1,7 +1,7 @@
 /* Storage allocation and gc for XEmacs Lisp interpreter.
    Copyright (C) 1985-1998 Free Software Foundation, Inc.
    Copyright (C) 1995 Sun Microsystems, Inc.
-   Copyright (C) 1995, 1996, 2001, 2002, 2003, 2004, 2005 Ben Wing.
+   Copyright (C) 1995, 1996, 2001, 2002, 2003, 2004, 2005, 2010 Ben Wing.
 
 This file is part of XEmacs.
 
@@ -3117,6 +3117,14 @@
   const struct lrecord_implementation *implementation
     = LHEADER_IMPLEMENTATION (lheader);
 
+  /* If we try to debug-print during GC, we'll likely get a crash on the
+     following assert (called from Lstream_delete(), from prin1_to_string()).
+     Instead, just don't do anything.  Worst comes to worst, we have a
+     small memory leak -- and programs being debugged usually won't be
+     super long-lived afterwards, anyway. */
+  if (gc_in_progress && in_debug_print)
+    return;
+
   /* Finalizer methods may try to free objects within them, which typically
      won't be marked and thus are scheduled for demolition.  Putting them
      on the free list would be very bad, as we'd have xfree()d memory in