From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Chris Vine Newsgroups: gmane.lisp.guile.user Subject: Re: Calling back scheme from C Date: Tue, 22 Sep 2020 15:47:35 +0100 Message-ID: <20200922154735.1b5cee31c2d7e369fe72024b@gmail.com> References: <3a0ccd31a195f1544038b4ccc5ff1d15667a8e0d.camel@divoplade.fr> <20200922105026.5783d9ab0dd3641391cdd8c9@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7526"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-user@gnu.org To: divoplade Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Tue Sep 22 16:48:54 2020 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kKjbC-0001lk-0E for guile-user@m.gmane-mx.org; Tue, 22 Sep 2020 16:48:54 +0200 Original-Received: from localhost ([::1]:52334 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKjb7-0005iv-Rv for guile-user@m.gmane-mx.org; Tue, 22 Sep 2020 10:48:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54570) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKjaL-0005ip-Lw for guile-user@gnu.org; Tue, 22 Sep 2020 10:48:01 -0400 Original-Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:50862) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kKjaJ-0001eT-Ew for guile-user@gnu.org; Tue, 22 Sep 2020 10:48:01 -0400 Original-Received: by mail-wm1-x32d.google.com with SMTP id e17so3654406wme.0 for ; Tue, 22 Sep 2020 07:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=djSVahvQ8Qc30w2KiUcy9XtcKzzsD/yrliVPHJKlFwY=; b=upvQ8IVR/0vpAli79lmozKwkilmrHVCV1EpF6M3KuzQfVeAlg0vm2dhPCyRddzb6Cm 7NwY6/L34ai5GtGS2hgEXYfISPShQ9LsoKn0lvDuOSlgEmJpmJZLhgGJ/XMD/q5cv5MU piqF2OD9wnoF9okj0cvGHJpii9ix0ssRkVI8atMgbzSwa9lih2raAIov7iUG406yuRM/ VKA5Ln9Xwl9GIG535rfVxZWv1UEoQp61mbwLWS8dzblwMj+vFxzY3WroHzv3dI/8MlN4 NC0O0w/WbwO6vKJNv8tGtwm2LTwzxNgceGkQBCYzrLga1SyFtQskWRg+5hskunRDOnuN tplg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=djSVahvQ8Qc30w2KiUcy9XtcKzzsD/yrliVPHJKlFwY=; b=uSNxW04RWuemq1GR0sNaMUCfaAAv/wu3KtUxdJ3Y8Mv/Uub7koa0AuWFVKg+KB1DlM RmbjLRx6zVKroNLEigkbe2W96XMy/mieUoipmoCTXDTbSRcp64ALY9N26ad5Czqesg8b AEELx3mRs3G1mdWR768Rq6RwedVqwuaICAGcnX+GfF3wUvVtDkGOq14yxJoXxhEM1AnK GulGKxbKkRDXpwUn9DnQ11DVRaGTsEFSbLURg15RlkL2868Wpu8srwIeruZfPB5okB7D tQLVi1nTkr5465NkDMllgQ87XGyeT6X9mtQ9IUi6TZoHyXACWplGwDPUx7IR9Tv5y3AV E88A== X-Gm-Message-State: AOAM533R48ocaehM2jBMOhZ9aP27GECJ9S9v1rF6SMJM2i9D3+279RE8 jM4AyK+ia/FT2hDQAL9Dxh8= X-Google-Smtp-Source: ABdhPJzWvsYSyartC8CkSDmdwDmQUKgWB5JAQgVFcmKZt/vOcbHFSOa4V4Ni7Kk5k6pxJTUbP8QtjA== X-Received: by 2002:a1c:4b17:: with SMTP id y23mr1411030wma.162.1600786077946; Tue, 22 Sep 2020 07:47:57 -0700 (PDT) Original-Received: from dell.homenet (81-174-209-196.pth-as2.dial.plus.net. [81.174.209.196]) by smtp.gmail.com with ESMTPSA id h76sm5591311wme.10.2020.09.22.07.47.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Sep 2020 07:47:57 -0700 (PDT) Original-Received: from dell.homenet (localhost [127.0.0.1]) by dell.homenet (Postfix) with SMTP id 0FA73422374; Tue, 22 Sep 2020 15:47:36 +0100 (BST) In-Reply-To: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-unknown-linux-gnu) Received-SPF: pass client-ip=2a00:1450:4864:20::32d; envelope-from=vine35792468@gmail.com; helo=mail-wm1-x32d.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.io gmane.lisp.guile.user:16948 Archived-At: On Tue, 22 Sep 2020 12:36:15 +0200 divoplade wrote: > Hello, >=20 > Le mardi 22 septembre 2020 =E0 10:50 +0100, Chris Vine a =E9crit : > > 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. >=20 > 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.