From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id aJpONuTyPWBmEwAA0tVLHw (envelope-from ) for ; Tue, 02 Mar 2021 08:10:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id SFslMuTyPWBSPQAAB5/wlQ (envelope-from ) for ; Tue, 02 Mar 2021 08:10:12 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 1460921519 for ; Tue, 2 Mar 2021 09:10:12 +0100 (CET) Received: from localhost ([::1]:43352 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lH06b-0001Xs-GV for larch@yhetil.org; Tue, 02 Mar 2021 03:10:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42050) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lH06U-0001XY-Sr for bug-guix@gnu.org; Tue, 02 Mar 2021 03:10:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:40080) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lH06U-0006aT-A0 for bug-guix@gnu.org; Tue, 02 Mar 2021 03:10:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lH06U-0006cQ-42 for bug-guix@gnu.org; Tue, 02 Mar 2021 03:10:02 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#46796: Cuirass & pointer finalization. Resent-From: Mathieu Othacehe Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 02 Mar 2021 08:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46796 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Received: via spool by 46796-submit@debbugs.gnu.org id=B46796.161467254825371 (code B ref 46796); Tue, 02 Mar 2021 08:10:02 +0000 Received: (at 46796) by debbugs.gnu.org; 2 Mar 2021 08:09:08 +0000 Received: from localhost ([127.0.0.1]:51626 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lH05c-0006b9-1Q for submit@debbugs.gnu.org; Tue, 02 Mar 2021 03:09:08 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52206) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lH05a-0006ad-Am for 46796@debbugs.gnu.org; Tue, 02 Mar 2021 03:09:06 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35545) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lH05U-00064t-QO; Tue, 02 Mar 2021 03:09:00 -0500 Received: from [2a01:e0a:19b:d9a0:8de0:390a:b2be:8c89] (port=56946 helo=cervin) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lH05S-0005Bu-On; Tue, 02 Mar 2021 03:08:59 -0500 From: Mathieu Othacehe References: <8735xihq60.fsf@gnu.org> <87ft1hvfm4.fsf@gnu.org> <87k0qrusde.fsf@gnu.org> Date: Tue, 02 Mar 2021 09:08:56 +0100 In-Reply-To: <87k0qrusde.fsf@gnu.org> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Mon, 01 Mar 2021 10:37:33 +0100") Message-ID: <87mtvmnfjb.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 46796@debbugs.gnu.org Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1614672612; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post; bh=espW6W0v/8Ky3vQ2QP2H5uiszZhYUsofYHoJtdyl1Bs=; b=d6dQFXN+VAXIwxRyI8oe34Sxxa9yV61GmQydXp6yZcbAqRJJSWgDT5mxwyDPbOjGs94M02 fkKuxpbmmtTxXRxFn7Uw00v5iIQ3TCld7NOu+H1FzX0WFrLbIJvU3Mj/R+POIZPimizKSK EzLDOx108WPuX3evgSmDpAoUZVjIec+6KNqXOT8fyjT4HnObW2t3QN0XjX79lsv86oVUVf stFdkKqmRNNWqQug7ZVNfC3css3Hmi/ut4WSFKQyh639/8PMNS6K8vaf7m+v3FBoYU3AVO gQvWd/xQZc/ZGTSh00sDEldi6fctoqjOqkkWOHuRUmu22eTTQaD/3dqgt5dLpw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1614672612; a=rsa-sha256; cv=none; b=GSCxcP0bXT1OHz4Zilw15dJplon0sfqQ57lUxuIxgV2fgx973P2BGill6ZxSLnPMFjwsso Kg839u+4iVzDOflj8D6ZfG25W/wy7Vfy6gtPRMMXmxxW/U0s06/5AJAGC2Hhh4maZWuM1m IW6ygOgxhHGG6iHHiydha3PtaFNCQxYo8tPmlw4t2BpiGnaOunaYfg3RAGnV2nR532a6c9 BA2Wl54TXvM/GzGJY2Z2pLSGkfy6+9RCyCFeDSyqjzsKRCrg1RxhVIcLf37GMomAP6+mot dA/Wzh5FeE8CvJxVBplUFzThEIsOe369T4KoKhwUR6fYvtjN9rZaa4xt1BzIdQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Spam-Score: -2.86 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: 1460921519 X-Spam-Score: -2.86 X-Migadu-Scanner: scn0.migadu.com X-TUID: VNpg6GPrPEN7 Hey Ludo, Many thanks for your help here, it feels great to have your support as always. > First, is this function idempotent? (Is it OK to close an msg_t > multiple times.) The zmq_msg_close function is mostly responsible of freeing the memory allocated by ZMQ to store the data associated with the message. I think it is safe to use it multiple times and from different threads. It is not responsible of freeing the zmq_msg_t structure itself which is allocated by the user, usually on the stack in C programs. I have written a small reproducer of the situation: --8<---------------cut here---------------start------------->8--- (use-modules (system foreign) (rnrs bytevectors)) (define close (dynamic-func "test_close" (dynamic-link "/home/mathieu/tmp/libtest"))) (let loop () (let* ((bv (make-bytevector 64)) (ptr (bytevector->pointer bv))) (set-pointer-finalizer! ptr close) (loop))) --8<---------------cut here---------------end--------------->8--- this program creates a bytevector of 64 bytes and attaches the C function "test_close" as a pointer finalizer to the bytevector pointer. This function looks like: --8<---------------cut here---------------start------------->8--- int test_close (void *x) { int i; char *v = x; for (i = 0; i < 64; i++) { v[i] = '1'; } return 0; } --8<---------------cut here---------------end--------------->8--- It overrides the bytevector content, that should cause a segmentation error if the bytevector is already freed. And it does indeed, which makes me think that despite the weak reference between the pointer object and the bytevector, the bytevector is already GC'd when the finalizer is called. I'm now using guardians in Guile-Simple-ZMQ instead of pointer finalizers, and do not experience crashes anymore, but I would really like to understand what's happening here. Any clues :)? Thanks, Mathieu