Michael O'Connor wrote:
>I'm getting a problem when I repeatedly run a block of
>Lisp code, the code block is read using cl_read(),
>then run several times by calling si_safe_eval().
It may happen that your lisp data (I assume you store your lisp code as
a list) has been garbage collected. If you did not store this code in a
lisp global variable, or register a C variable using
"ecl_register_root(&my_c_variable)", then the garbage collector will not
find this data and at some point reclaim it for future use (for
instance, cl_read() might get this memory for reading another list).
The Boehm-Weiser garbage collector is a very powerful one, in that if
configured with default settings it will scan both the stack and the
data segment of your C/C++ program looking for variables that contain
pointers to memory that should be preserved.
However, this has an important drawback: by scanning the data segment,
the garbage collector will always find references to dynamically loaded
libraries, and thus ECL cannot garbage collect pieces of C/C++ code that
have been compiled using COMPILE-FILE and loaded using LOAD.
I would recommend you to use one of the alternatives from the first
paragraph, as this leads to less false roots (i.e. the garbage collector
has a better knowledge of what is lisp data and what is not). But if
this is not an option, simply set "GC_no_dls=0".
>The gdb debugger tells me that the code block is
>modified at some point between the 25th and 26th run
>(which I wouldn't expect, but which would probably
>explain what's happening). A gdb watchpoint indicates
>this is occurring in function GC_reclaim_clear4()
>which implies that the code block is being
>garbage-collected I think (it's hard to tell exactly
>what's going on as gdb doesn't have a good stack trace
>at this point - I'm guessing the gc code does stack
>manipulation - ?).
No. What happens is that, by default, ECL is compiled with flag
"-fomit-frame-pointer", because it makes the APPLY() routine much much
smaller. Just look in build/c/Makefile and remove this flag to get
"backtrace" in your debugger.
Max-Planck-Institut fuer Quantenoptik +49/(0)89/32905-345
Hans-Kopfermann-Str. 1, D-85748 http://www.mpq.mpg.de/Theorygroup/CIRAC/
Garching b. Muenchen, Germany Juan.Ripoll@...