This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: guile-gtk 0.17
- To: Jim Blandy <jimb at red-bean dot com>
- Subject: Re: guile-gtk 0.17
- From: Greg Badros <gjb at cs dot washington dot edu>
- Date: 18 Sep 1999 22:20:23 -0700
- Cc: guile at sourceware dot cygnus dot com
- References: <19990915221659.26979.qmail@.netaddress.usa.net> <qrrr9jzu8bg.fsf@elwha.cs.washington.edu> <87iu5afy4c.fsf@zagadka.ping.de> <qrriu59tmzr.fsf@elwha.cs.washington.edu> <m3vh975w7n.fsf@savonarola.red-bean.com>
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