[Ecls-list] gc problem

Juan Jose Garcia Ripoll jlr at mpq.mpg.de
Wed May 26 02:16:58 UTC 2004


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.

Regards,

Juanjo

-- 
Max-Planck-Institut fuer Quantenoptik	+49/(0)89/32905-345
Hans-Kopfermann-Str. 1, D-85748		www.mpq.mpg.de/Theorygroup/CIRAC/
Garching b. Muenchen, Germany		Juan.Ripoll at mpq.mpg.de






More information about the ecl-devel mailing list