From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id mMqrHsZwPmCAXAAA0tVLHw (envelope-from ) for ; Tue, 02 Mar 2021 17:07:18 +0000 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id MFx3GsZwPmBUfgAA1q6Kng (envelope-from ) for ; Tue, 02 Mar 2021 17:07:18 +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 B46562DF3E for ; Tue, 2 Mar 2021 18:07:17 +0100 (CET) Received: from localhost ([::1]:56882 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lH8UO-0008Hm-Dc for larch@yhetil.org; Tue, 02 Mar 2021 12:07:16 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45414) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lH8QI-0003hr-Q0 for bug-guix@gnu.org; Tue, 02 Mar 2021 12:03:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:42550) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lH8QI-0006eZ-IN for bug-guix@gnu.org; Tue, 02 Mar 2021 12:03:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lH8QI-0005rL-F2 for bug-guix@gnu.org; Tue, 02 Mar 2021 12:03: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 17:03: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.161470457522510 (code B ref 46796); Tue, 02 Mar 2021 17:03:02 +0000 Received: (at 46796) by debbugs.gnu.org; 2 Mar 2021 17:02:55 +0000 Received: from localhost ([127.0.0.1]:54096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lH8QB-0005r0-2E for submit@debbugs.gnu.org; Tue, 02 Mar 2021 12:02:55 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55698) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lH8Q8-0005qn-Mm for 46796@debbugs.gnu.org; Tue, 02 Mar 2021 12:02:53 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43718) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lH8Q1-0006bD-AN; Tue, 02 Mar 2021 12:02:46 -0500 Received: from [2a01:e0a:19b:d9a0:48b9:53dd:55a0:354a] (port=51904 helo=cervin) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lH8Pz-0002sU-3P; Tue, 02 Mar 2021 12:02:45 -0500 From: Mathieu Othacehe References: <8735xihq60.fsf@gnu.org> <87ft1hvfm4.fsf@gnu.org> <87k0qrusde.fsf@gnu.org> <87mtvmnfjb.fsf@gnu.org> <87blc1oeba.fsf@gnu.org> Date: Tue, 02 Mar 2021 18:02:40 +0100 In-Reply-To: <87blc1oeba.fsf@gnu.org> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Tue, 02 Mar 2021 14:50:01 +0100") Message-ID: <87im69bia7.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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=1614704838; 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: content-transfer-encoding:content-transfer-encoding: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=8pltqQwfMDTJ+RwQW5auHBSjmtfdbnTbknkdNlS6ycU=; b=Ls8VPr6P94CE6EOKGj3xlqqMecwfpVjY5K43ghesTozBAkkBDPbG+wv+sp51GNjK0/TKYf AhBXDi31JHJyfGSgtF561Ewzj18P9eDqw14IqKN8zX8hLGWZ1gXou8IhQZeBC6Fv8vWJiI gYxzSE2e8XuCTENfRVJ1FpH3PaGfSGC0HdU5U15qerIeDjWLV0odAiYCl7uhrWn/wIUYxn 6+GXv/5L1t+jGxUYGYa+uRZ7sZL5H1yAhiy9toJGLXlvStxCjQE9zJtHbFgi/6mi+eK7Qt aEJOPOZ5CQApERK5SONxsXovMbalZ7m3HJPCWTj2zOsMbIwDidsbkZmPFVf4kg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1614704838; a=rsa-sha256; cv=none; b=DJLX+jFYgL6gAnCS/mhgCuVEEbhLEgsm7eKcGq8pUg5J/mY7vzCHcBPKJgDw+M4fgr3AoJ L69a8Rzce52rsFRziQe8a7rWF7Gcm6r8//5Dx+z9GwhLxcOlYjPa/95hIn5Sa4pTkXCsN6 0dDrL+JVcugyIPfEfpfj5PRGITW/57hxnqen12EfLRKPOET3mA24PwQFbD2ZrhjTxBwhKQ 5GT9ExKFaDxyR+VrNrjLhxZJAWfonfW29LEaGTQaUZ+aqyJLwL+Yc4IG2RxMYZmO4iQlsa 2S5JOeiYzTNtJk3NuVct5kFyV7K7lQGkWH/fsxxI7HKrv8Guvr3ZZ7rtl1LZAA== 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: B46562DF3E X-Spam-Score: -2.86 X-Migadu-Scanner: scn1.migadu.com X-TUID: bbpHgwsPI3CF Hey, > Hmm I think the bytevector and the pointer object can be finalized in > the same GC cycle; when that happens, you have no guarantee as to the > order in which they are finalized. That would explain the crashes indeed. > But=E2=80=A6 is it really similar to your ZMQ issue? There you had messa= ge > object wrappers (as per =E2=80=98define-wrapped-pointer-type=E2=80=99) an= d a pointer > object to the underlying C object, right? I think the only difference is that the reproducer doesn't introduce the wrapped pointer object. Using ZMQ, the message creation looks like: zmq-msg-init Bytevector creation with make-bytevector at address P Bytevector initialization with zmq_msg_init(P) Install zmq_msg_close as finalizer on P Message wrapping using (pointer->message P) Return the wrapped message The user can then operate on the wrapped message by passing it to other message API procedures such as zmq-message-size. Those procedures will call ZMQ using the underlying pointer. The bytevector/pointer object undetermined GC order is really problematic then. I'm not sure why I'm not experiencing this crash using Guardians since they are also using finalizers. The ultimate work around would be to leave the message closing responsibility to the user but that would be sad. Do you know if there's another to prevent the bytevector from being collected before the pointer object? Thanks, Mathieu