[CM] Are s7 GC questions in scope here?

[Norman Gray]

Greetings.

Would s7 questions be in-scope on this list?  Specifically questions about s7's FFI and GC?

Is there any wisdom about how to approach, or reason about, s7's garbage collection support?  I confess to being stumped.

I'm writing something which goes back and forth between the s7 world and the C world.  The C main program promptly hands over to a scheme main program, which calls out to C (specifically lex/yacc parsers), which in turn call back to scheme for non-trivial bits of work.  I _thought_ I was doing the right thing by employing s7_gc_protect_via_stack strategically, while being aware that having C functions call back to scheme ones could stress my reasoning there.  The programs in the fairly comprehensive test-suite probably aren't big enough to test that I'm doing the right thing, though, even when I compile with GC_TEMPS_SIZE quite low.

I think I'm right that, if scheme procedure (sf1) is implemented in C function cf1(), which calls (sf2) via s7_call, then if cf1() creates an s7 object, or obtains one returned from (sf2), and calls s7_gc_protect_via_stack with it, then that object, and anything it directly or indirectly refers to, is protected until (sf1) returns.  Right?  I presume that implies that the caller of (sf1) takes ownership of the return value in time for that return value to be safe from GC?

It appears to me that, if the above reasoning is correct, then I'm doing something wrong enough that my program seems to simply die abruptly, at the time that the return value of (sf1) is received.  No error messages, no stack traces, no non-zero exit value, no mention of free cells, just... end.  I'm fairly sure this is a GC-related problem, since it emerges only when it works on a larger quantity of input.

My problem is that, after lots of fprintfs, and scattering some s7_gc_protect here and there (which should be a pretty blunt instrument), and compiling with -DGC_TEMPS_SIZE=1000000 and 128, and casting around to see if there's a handy rooster I can sacrifice, I remain sufficiently in the dark, that I can't work out where to look next, nor how I'd make a reduced toy program to demonstrate this.  Any toy program that worked could of course be just luck.

I've tried invoking the support in "debug.scm", but even when adding (load "debug.scm") (break parse-aux-file) -- where the latter is what I'm confident is the problematic function -- the program still exits, apparently normally, just after parse-aux-file returns.  Including in a debugger.

Is there perhaps a way of doing valgrind-like memory accounting that might show me what I'm missing?

Any wisdom about what stones to look under would be most appreciated.  *weep*...

Best wishes,

Norman


-- 
Norman Gray  :  https://nxg.me.uk