Need help finding heap corruption bug

[Pat Lasswell]

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 < address@hidden> wrote:

"Pat Lasswell" < address@hidden> 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