"Marc" == Marc Feeley feeley@iro.umontreal.ca writes:
Marc> The source of the problem is that you are storing references Marc> to Scheme objects (i.e. the ___SCMOBJ type) in places that the Marc> garbage collector has no knowledge of (i.e. C variables), so Marc> when there is a GC these references are not updated when the Marc> object referenced is moved by the GC.
I had a feeling this might be the problem, but not the vocabulary to express it ;)
Marc> [Side note: amusingly the code actually works for f64vectors Marc> of length greater or equal to 128 because those vectors are Marc> allocated as "still" objects that aren't moved by the GC!]
Yeah, I tried testing it with larger and larger vectors and couldn't get the segfault ;)
Marc> 1) call the macro ___F64VECTORREF (from gambit.h) which does Marc> not allocate a flonum, and hence does not invoke the GC
Okay, duh: I guess I'll check gambit.h next time I write a C function.
Marc> 2) use an inline code c-lambda where the vector is passed in Marc> one of the ___argxxx variables. These variables ***are know Marc> to the GC and will be updated properly***. But don't store Marc> their content in another C variable!
Good to know the difference.
Now I'm getting a segfault at mark_continuation() (mem.c:2430).
if (ra1 == ___GSTATE->internal_return) { ___WORD actual_ra = ___FP_STK(fp,___RETI_RA); ___RETI_GET_FS_LINK_GCMAP(actual_ra,fs,link,gcmap,nextgcmap) ___COVER_MARK_CONTINUATION_RETI; } else { here===> ___RETN_GET_FS_LINK_GCMAP(ra1,fs,link,gcmap,nextgcmap) ___COVER_MARK_CONTINUATION_RETN; }
This happened before when I was accumulating a list instead of outputting and then throwing away each run of the simulation --- am I just using up memory and the GC can't handle it? (is that even possible?) Or does it mean that I have other unreachable objects unknown to the garbage collector?
Joel