guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Calling back scheme from C


From: Chris Vine
Subject: Re: Calling back scheme from C
Date: Tue, 22 Sep 2020 15:47:35 +0100

On Tue, 22 Sep 2020 12:36:15 +0200
divoplade <d@divoplade.fr> wrote:
> Hello,
> 
>  Le mardi 22 septembre 2020 à 10:50 +0100, Chris Vine a écrit :
> > This may not be your issue.  I offer it as something I had to deal
> > with
> > in code of my own to prevent incorrect collection for closures of
> > callbacks executed by a C event loop.
> 
> It does not seem to fix it on my side. Could you share your callback
> closure example?

I haven't got anything sufficiently compact to be postable.  However
the principle is fairly straightforward: when carrying out a mark, the
GC can see any memory dynamically alloced by scm_gc_malloc and
cognates (but _not_ SCM pointers held in memory allocated by
scm_gc_malloc_pointerless), and can also see global variables, static
data sections, function arguments, registers and variables on the C and
Scheme stacks, but not anything else, and in particular it cannot see
anything held on the C heap (memory formed by malloc and cognates).  So
if your code ends up keeping a SCM object by pointer in the C heap, and
there are no other live references to the object which the mark phase
can see, then it can be freed by the GC at any time and if so you are
left with a dangling pointer in the C heap.

Typically this can occur with SCM objects held by pointer as closures
for C callbacks.

If you have applied scm_gc_protect_object to any suspect SCM objects in
your program, and that doesn't resolve the issue, then that is not the
problem.  If it does resolve the issue then you need to decide how and
when subsequently to apply scm_gc_unprotect_object to them to avoid
memory leaks.  But that is a second stage operation from the diagnosis.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]