unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Chris Vine <vine35792468@gmail.com>
To: divoplade <d@divoplade.fr>
Cc: guile-user@gnu.org
Subject: Re: Calling back scheme from C
Date: Tue, 22 Sep 2020 15:47:35 +0100	[thread overview]
Message-ID: <20200922154735.1b5cee31c2d7e369fe72024b@gmail.com> (raw)
In-Reply-To: <e997993cfbdb882f140a8bd00e18025f743fbb34.camel@divoplade.fr>

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	other threads:[~2020-09-22 14:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-22  6:25 Calling back scheme from C divoplade
2020-09-22  9:50 ` Chris Vine
2020-09-22 10:36   ` divoplade
2020-09-22 14:47     ` Chris Vine [this message]
2020-09-22 15:48 ` divoplade

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200922154735.1b5cee31c2d7e369fe72024b@gmail.com \
    --to=vine35792468@gmail.com \
    --cc=d@divoplade.fr \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).