I found the cause of the bug, but more by happenstance than intent.

I had attempted to do something clever during metaclass initialization --
attempting to ensure all class instantiations had a specific slot.  I consed
a new initargs parameter but failed to produce exactly what the base
implementation expected.  I didn't track down the root cause, opting rather
to have a less clever, but probably better-structured approach of adding
that slot to an instance of the metaclass from which all clients derive.
Given the obtuse code path necessary to trigger the corruption, I am content
to leave it be; if someone thinks it worth investigating, let me know and
I'll track it down.

Thanks for all the feedback.  I'll keep (gc) in mind if something like this
happens again.

pat
On 9/23/06, Neil Jerram < neil@ossau.uklinux.net> wrote:
>
> "Pat Lasswell" < imofftoseethewizard@gmail.com> writes:
>
> > I have two questions.  Is there something intrinsically wrong with with
> setting
> > the current module to the one on which I am actively working and then
> just
> > reloading that file rather than the entire suite?
>
> No.
>
> >
> > My second question is this: given that the answer to 1) is no, how do I
> track
> > this pest down?
>
> Based on the other messages in this thread, it doesn't sound like
> there's an obvious overall problem with Guile on MacOS.  It may still
> be MacOS-specific, though.  Do you know whether the same steps cause
> problems on Linux?
>
> >  Placing an undefined identifier, say 'x', at various points in
> > one of the modules will sometimes produce the appropriate warning,
> sometimes
> > produce a segfault, other times a bus error or illegal instruction or
> even an
> > abort during gc.  I have run attached to gdb, but I get a deep stack
> (131
> > frames) ending with, e.g.
> >
> > #0  scm_gc_sweep () at ../../../src/guile-1.6.8/libguile/gc.c:1729
> > #1  0x0021f573 in scm_igc (what=0x26c720 "cells") at ../../../src/guile-
> 1.6.8/
> > libguile/gc.c:1161
> > #2  0x0021fa83 in scm_gc_for_newcell (master=0x273440,
> freelist=0x273438) at ..
> > /../../src/guile- 1.6.8/libguile/gc.c:985
> > #3  0x00238aef in scm_cons (x=0x6826c0, y=0x2974) at ../../../src/guile-
> 1.6.8 /
> > libguile/pairs.c:84
> > #4  0x00216b87 in scm_deval (x=0xc3028, env=0x682480) at ../../../src/
> > guile-1.6.8/libguile/eval.c:2835
> > #5  0x00219af5 in scm_deval (x=0xc3030, env=0x682480) at ../../../src/
> > guile-1.6.8/libguile/eval.c:2819
> >
> > Are there guile primitives to verify the heap?
>
> Apart from (gc), no. :-)
>
> The only approach I can think of right now is to look at the detail of
> why scm_gc_sweep is aborting and work back from there.  Anyone have
> any other ideas?
>
> Regards,
>      Neil
>
>