Re: guile-gtk 0.17

[Jim Blandy <jimb at red-bean dot com>]

> > > The bugs I've seen in the GC are my main short-term problem.
> > 
> > Bugs that surface during GC are indeed very hard to track down.  My
> > best advice is to try to narrow down the cause of it to the simplest
> > piece of code possible.  This might be difficult, too, because GC
> > invocation is quite asynchronous.  You might even want to patch
> > libguile to run the GC more deterministically, like after each cons.
> 
> This would be a nice run-time option in developer builds of guile:
> 
> (set-gc-after-each-cons! #t)
> 
> It'd be expensive (even noticeable, perhaps, when turned off), but could 
> really help on these tricky problems.

When you've got a program that reliably crashes in GC, it would be
easy to get Guile to help you narrow down the source of corruption.
Think of GC as a big consistency check, which runs over all your data
structures checking for problems.

Guile should have a way (consult an environment variable, perhaps) to
force a GC every N cell allocations after the M'th.  Then you could
run guile several times and narrow in on exactly which allocation is
the last one to occur when the heap is valid.  Then you know that the
heap must be corrupted between the K'th and K+1'th allocation.  If
your program allocates regularly (and you can always arrange that it
does so), then there usually shouldn't be too much code to step
through and watch carefully.

Ideally, the process would be automated; there would be a script which
runs Guile over and over with whatever arguments you supply until it
knows exactly when the heap gets corrupted.  If it's not fine-grained
enough for you, add calls to gh_cons at random places until it is.