From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 9BB5C7FECC for ; Fri, 17 Jun 2016 21:41:27 +0200 (CEST) IronPort-PHdr: 9a23:0JRKiRa1UPf9kCTkaLvAGMT/LSx+4OfEezUN459isYplN5qZpci5bnLW6fgltlLVR4KTs6sC0LqH9fG4EjVcud6oizMrTt9lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUiv2OQc9HOnpAIma153xjLDjvcyLKFwU3HKUWvBbElaflU3prM4YgI9veO4a6yDihT92QdlQ3n5iPlmJnhzxtY+a9Z9n9DlM6bp6r5YTGfayQ6NtRrVdCHEiMnspzMztrxjKCwWVtVUGVWBDroRSnQuNwR3lX5G55ib2qet7myyeeMr9RLUwcTm+6L1sS1nuhTtRZG1xy33elsEl1PETmxmmvREqm4M= Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=edwin+ml-ocaml@etorok.net; spf=Pass smtp.mailfrom=edwin+ml-ocaml@etorok.net; spf=None smtp.helo=postmaster@mail.etorok.net Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of edwin+ml-ocaml@etorok.net) identity=pra; client-ip=62.210.252.135; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of edwin+ml-ocaml@etorok.net designates 62.210.252.135 as permitted sender) identity=mailfrom; client-ip=62.210.252.135; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.etorok.net) identity=helo; client-ip=62.210.252.135; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="postmaster@mail.etorok.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CfAgDqUWRX/4f80j5dgz5WK1KCfrdlgXoihXADAgKBJTgUAQEBAQEBAQFkJ4IxghoBAQEDAQwXBAsBDRUlAQMLCQIYAgIYDgICVxMIAQGIJAwKkw6cNmeEQgeMLAEIgQGHHQiCToQsYII1glqOaYoNhgWIJI8ij3UeNoI7gTg5Mog4gUMBAQE X-IPAS-Result: A0CfAgDqUWRX/4f80j5dgz5WK1KCfrdlgXoihXADAgKBJTgUAQEBAQEBAQFkJ4IxghoBAQEDAQwXBAsBDRUlAQMLCQIYAgIYDgICVxMIAQGIJAwKkw6cNmeEQgeMLAEIgQGHHQiCToQsYII1glqOaYoNhgWIJI8ij3UeNoI7gTg5Mog4gUMBAQE X-IronPort-AV: E=Sophos;i="5.26,485,1459807200"; d="scan'208";a="222906852" Received: from mail.etorok.net ([62.210.252.135]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2016 21:41:27 +0200 Received: by mail.etorok.net (OpenSMTPD) with ESMTP id 2f9a3ded for ; Fri, 17 Jun 2016 19:41:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=etorok.net; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=ml; bh=GEBn0yxM5OIPUY kpZrmrHAIjXN0=; b=Ztp5VbWaz0kLDb/BnZSvIJ+SV9uytHmKDZrbYuMlBP7P2v CH3EAUFMWu9arklnGBc5WaB0Vc5HJfMDc5zX2kKlXViXvtFpGaYjo8rkqfguWrZ2 F5L1qadZ0N7uZN4lj+vGiH+L69vt3oLhk4qZteKTU9IbOjndCnAyFpk0fsBXk= DomainKey-Signature: a=rsa-sha1; c=simple; d=etorok.net; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; q=dns; s=ml; b=qq3W65/h X4ykrwTjwikN9MC5uChm6+OmC0C33F6f1UUOMx7gqo5kJz+fszy9SpdJGjbNczIg sd9Jg+DzrUgF3c/oBmN35AYX3kgPPrijBEI/48z9xbUIQjqqOmbWP4ZsEgaa2z0Q KAiZTHGl7Z9fc531waMSBi2892KoaW5xKRs= Received: by mail.etorok.net (OpenSMTPD) with ESMTPSA id 5ef36762 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Fri, 17 Jun 2016 19:41:26 +0000 (UTC) To: caml-list@inria.fr References: <7182303B-EBFF-4CFC-A7DF-B5C7A059509F@marneu.com> From: =?UTF-8?B?VMO2csO2ayBFZHdpbg==?= Message-ID: <3673db34-9350-a9b1-fcd5-e7593ba0fd01@etorok.net> Date: Fri, 17 Jun 2016 22:41:25 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <7182303B-EBFF-4CFC-A7DF-B5C7A059509F@marneu.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] Presumed bug in OCaml's garbage collector or in its Weak module... On 06/17/2016 09:09 PM, "Martin R. Neuhäußer" wrote: > Dear all, > > after an intense week of debugging some large C-bindings, I presume to have found a bug in OCaml’s garbage collection code or in its Weak module. > To summarize, it seems as if OCaml’s garbage collector and its Weak module sometimes release a custom block (by calling its finalizer) too early, i.e. when it is still reachable. > > I hesitate a bit before opening an „official“ issue on Mantis as I might very well overlook some detail. Therefore I’d like to double-check some of the assumptions that I have made when writing my C-stubs. Any corrections are highly welcome: > 1. Custom blocks may be moved around in memory by the GC, but they are never duplicated. > 2. The finalizer for each custom block that is allocated by caml_alloc_custom is called at most once. > 3. The finalizer is never called for blocks that are still alive; stated otherwise, a block that has been finalized can never been presented as a value to a C-stub anymore. Shallow copies don't seem very safe in the presence of out-of-OCaml-heap C pointers [*]. Perhaps Weak.get_copy should raise if it encounters a Custom_tag? The custom value may contain C pointers, that may get invalidated or changed if the custom value has a finalizer (as in the testcase): When the original weak value has no more references it gets the finalizer invoked, and gets garbage collected (in this case it changes unique_id to c_data_invalid_id, but it might as well free it instead causing a crash). Meanwhile the copy made through Weak.get_copy still lives, and shares the copied custom value (pointer) from the weak value that got finalized. Operations on the copied value (e.g. comparison/hashing) will try to access the custom value, which points to c_data_invalid_id. > There is a small example program available on github: https://github.com/martin-neuhaeusser/ocaml_bug where the above assumptions seem to be violated. [*] AFAICT a shallow copy is created by WeakDummySet.find -> Weak.get_copy Best regards, -- Edwin Török | Co-founder and Lead Developer Skylable open-source object storage: reliable, fast, secure http://www.skylable.com