I hit reply when I meant repl-all:
-------- Original Message --------
Subject: Re: [CM] Segmentation fault in s7 triggered by recursive
expression
Date: 2025-07-16 06:09
From: [email protected]
To: John M693 <[email protected]>
Is the trick turning on (compiling) S7_DEBUGGING=1?
That's the first thing I do. There's a short section in
s7-ffi.html about the internal debugger -- I should expand
it. The internal debugger checks nearly everything the
interpreter does, so s7 runs 10 to 20 times slower,
but in most cases, it will pinpoint the line where
things unravel. It also provides GC info about each
cell (where it was last allocated or freed etc), and
a bunch of undocumented functions to handle things
like analyzing the heap contents etc. If that isn't
enough, or if the bug was not caught early enough,
there's also the switch in s7.c, SHOW_EVAL_OPS, which
sends out an enormous log of the interpreter's adventures.
Even more detailed info can be generated via the
OPT_PRINT and DO_PRINT switches, though those are
more oriented toward questions like "why wan't this code
fully optimized". I always try to save a breaking
test case for s7test.scm (and full-s7test.scm),
and then run tools/auto-tester.scm overnight --
it is a sort of "fuzz tester" generating billions
of random scheme code fragments, then evaluating
them in various contexts. In the winter (when
my machines don't overheat) I run 60 cores of
this test 24/7. It is amazingly adept at finding
bugs. (It also runs up a power bill that PG&E
complains about).
_______________________________________________
Cmdist mailing list
[email protected]
https://cm-mail.stanford.edu/mailman/listinfo/cmdist
