[gambit-list] My New Segfault (Re: Tracking Down a Segfault)
Joel J. Adamson <firstname.lastname@example.org>
adamsonj at email.unc.edu
Fri Sep 5 12:35:49 EDT 2008
>>>>> "Marc" == Marc Feeley <feeley at 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);
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 J. Adamson
University of North Carolina at Chapel Hill
CB #3280, Coker Hall
Chapel Hill, NC 27599-3280
Before you reply to this email, please read
More information about the Gambit-list