Every subroutine marked with can trigger GC may invoke garbage-collection. garbage-collect moves all the CLISP non-immediate objects and updates the pointers. But the garbage-collect looks only on the STACK and not in the C variables. (Anything else would not be portable.) Therefore at every "unsafe" point, i.e. every call to such a subroutine, all the C variables of type object MUST BE ASSUMED TO BECOME GARBAGE. (Except for objects that are known to be unmovable, e.g. immediate data or Subrs.) Pointers inside CLISP data (e.g. to the characters of a STRING or to the elements of a SIMPLE-VECTOR) become INVALID as well.

The workaround is usually to allocate all the needed CLISP data first and do the rest of the computation with C variables, without calling unsafe routines, and without worrying about garbage-collect.

Run-time GC-safety checking is available when you build CLISP with a C++ compiler, e.g.:

$ CC=g++ ./configure --with-debug build-g-gxx

When built like this, CLISP will abort when you reference GC-unsafe data after an allocation (which could have triggered a garbage-collection), and gdb will pinpoint the trouble spot.

Specifically, when CLISP is configured as above, there is a global integer variable alloccount and the object structure contains an integer allocstamp slot. If these two integers are not the same, the object is invalid. By playing with gdb, you should be able to figure out the precise spot where an allocation increments alloccount after the object has been retrieved from a GC-visible location.

Generational garbage-collector uses memory protection, so when passing pointers into the lisp heap to C functions, you may encounter errors (errno=EFAULT) unless you call handle_fault_range(protection,region_start,region_end) on the appropriate memory region. See files

for examples.