This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: guile-gtk 0.17


Jim Blandy <jimb@red-bean.com> writes:

> > > > 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.

I added a configure time option for setting DEBUG_FREELIST, and a new
primitive `gc-set-debug-check-freelist!' to set the
scm_debug_check_freelist variable.  It'd be easy enough to have an extra 
flag and setter to run scm_gc() inside scm_debug_newcell(), too (would
only be available if configure had been built with --enable-debug-freelist).

Greg

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]