Andy Wingo escreveu: > Hi, > > I just merged master to guile-vm, but I'm not sure if I really wanted to > do that now. Normal test suites are failing: > > lt-guile: gc.c:604: scm_i_gc: Assertion `scm_cells_allocated == > scm_i_marked_count ()' failed. > /home/wingo/src/guile/vm/test-suite/standalone/test-use-srfi: line 27: > 29507 Aborted guile -q --use-srfi=1,10 > /dev/null <<EOF > (if (and (defined? 'partition) > (defined? 'define-reader-ctor)) > (exit 0) ;; good > (exit 1)) ;; bad > EOF > > guile --use-srfi=1,10 fails to run > FAIL: test-use-srfi > > This is on a core 2 duo, in 32-bit mode, configured as: > > CFLAGS="-g -O2" ./configure --with-threads --enable-maintainer-mode > --prefix=/opt/guile-vm > > So it seems that the new gc "cleanups" don't want you to touch mark bits > outside the mark phase. This is incompatible with other uses inside > guile itself, e.g. the SCM_DEBUG_CELL_ACCESSES == 1 case in inline.h, or
I am pushing a fix for this to master. > even the lazy smob case I wrote about here: > > http://thread.gmane.org/gmane.lisp.guile.user/6372 I would classify the use of mark bits outside of the mark phase as outside of the defined API. If you want to have weak pointer semantics, use a weak hashtable, or implement reference counting on the C side. I am actuallly inclined to add add abort() for anyone who calls scm_gc_mark() outside the marking phase. > There are more cases, rgrep for SCM_SET_GC_MARK in libguile/*.[ch]. I looked through all of these, and these all happen during the mark phase. > I'm going to commit an #if 0 around those asserts in the vm branch, > because I don't have the brain power to deal with it. (It is irritating > that I have to even write this mail.) Certainly if the near-term choice > is between inaccurate statistics and calls to abort(), I know which > choice I prefer... The statistics form the basis of the allocation strategy, so they are not a 'cute' feature. If these statistics go off, we overallocate, or spend too much time trying garbage collect when there is nothing to reclaim. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
