Re: scheme closures: crash during garbage collection

[gregory benison]

Is your master list global, or a list for each SMOB that wraps a
widget?

Global; it is created once and protected only once with
scm_gc_protect_object() at creation time; it is never freed; the same
master list is used for all scheme procedures in use as gclosures (no
matter which gobject they are attached to).

Sometimes there is no SMOB involved.  Consider a scheme closure
kept alive exclusively by gobject references (e.g., a toplevel window
contains a button which is connected to a callback written in scheme;
there need not be any scheme binding for the window or the
button).  Guile's GC must be told to leave alone this scheme
closure, even though there is no chain of references leading from it
back to any other scheme object.  This same scheme closure,
previously owned entirely by gobject's memory management system, can be
"adopted" by guile, if a scheme binding is created for some gobject
that has a chain of references leading to the scheme closure. 
Then, let's say that some gobject references die, so that now, the new
scheme binding is the only thing keeping our scheme closure alive
(through some intervening, arbitrarily long, chain of gobject
references).  This makes the scheme closure fair game for
destruction during guile's gc sweep.  The current guile-gnome
release responds by calling scm_gc_unprotect_object during the sweep;
my patch responds by
calling a function 'bridge_unmark' which can be seen as a gc-sweep-safe
replacement for scm_gc_unprotect_object (it removes the closure from
the protected list, allowing it to be destructed during a future gc
sweep.)

What is the best way to submit a patch for guile-gnome?
(I tried to follow the instructions in 'HACKING', but it seems that the
arch archive mentioned in there--
http://download.gna.org/guile-gnome/archive-2004 -- is no longer there.)

======================
Gregory Benison
Oregon State University
(541)-737-1876
address@hidden
======================