Reporting back: The problem was a bug in the bytecode compiler, and
commit 88d8ba00e0 is the repair.
The debugger works by modifying a program so that local variables are
mutable. Meanwhile, Philip's program uses the contracts in a way that
expands to `call-with-immediate-continuation-mark`. The
Since the crash is consistent, can you try a snapshot build from
https://pre.racket-lang.org/ to check whether the crash persists?
The only repair I remember since v6.12 that seems relevant is
55ffc24011. Your crash is consistent with the bug fixed by that commit,
but my guess is that it's
Thanks for the crash report! It doesn't immediately point to the
problem, but it's good starting point. I'll ask you for more debugging
help off-list, and we can report back here afterwards.
At Sat, 21 Apr 2018 05:11:10 -0500, Philip McGrath wrote:
> In a particular module, I can consistently
In a particular module, I can consistently trigger a segfault by opening
DrRacket's graphical debugger, setting a breakpoint, and evaluating an
expression at the REPL. I am using Racket 6.12 on Mac OS 10.13.2: I have
not (yet) tried to reproduce this on other platforms.
Unfortunately I don't have
Your C code doesn't cooperate with the "3m" garbage collector, which is
the way Racket is built by default. For example, the object that `env`
references might be moved by the GC without the `env` variable being
updated.
See
I'm trying to embed Racket into a test C program (minimal.c). I can
successfully compile it with clang on Mac OS X, but the program segfaults when
I try to run it. Any idea on what I'm doing wrong?
#include
#include
#include "base.c"
static int our_scheme_main(Scheme_Env *env, int argc,
6 matches
Mail list logo
