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 2D8637FECC for ; Fri, 17 Jun 2016 20:10:17 +0200 (CEST) IronPort-PHdr: 9a23:iVPARBbfmStJEUJgMpQJYFP/LSx+4OfEezUN459isYplN5qZpcuybnLW6fgltlLVR4KTs6sC0LqH9fG4EjVau96oizMrTt9lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUiv2OQc9HOnpAIma153xjLDjvcyLKFwS3nKUWvBbElaflU3prM4YgI9veO4a6yDihT92QdlQ3n5iPlmJnhzxtY+a9Z9n9DlM6bp6r5YTGY2zRakzTKRZATI6KCh1oZSz7ViQBTeIs1w3W2AS2j5JGBSNuBrzW5O0tirhqsJ83jObNIv4V+Zndy6l6vIhbRbylCYBAAR/x0fal8z8kRVWuljp8wR42JL8ZYiPMvdjOKjaeIVJFiJ6Qs9NWnkZUcuHZIwVAr9EZL4Aog== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=post@marneu.com; spf=Pass smtp.mailfrom=post@marneu.com; spf=None smtp.helo=postmaster@zulu1878.startdedicated.de Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of post@marneu.com) identity=pra; client-ip=62.75.236.16; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="post@marneu.com"; x-sender="post@marneu.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of post@marneu.com designates 62.75.236.16 as permitted sender) identity=mailfrom; client-ip=62.75.236.16; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="post@marneu.com"; x-sender="post@marneu.com"; 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@zulu1878.startdedicated.de) identity=helo; client-ip=62.75.236.16; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="post@marneu.com"; x-sender="postmaster@zulu1878.startdedicated.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DhBADLPGRX/xDsSz5dhBRLAbsQgXoiYIZzFAEBAQEBAQEBZCeCMYJEgQsCJgJfiEcBCaBEj2KQTQsBAQEBHQWBAYQugm+KFyuCLwWYcQGBMIRUiCSJQYVhj3MCHjaDcopnAQEB X-IPAS-Result: A0DhBADLPGRX/xDsSz5dhBRLAbsQgXoiYIZzFAEBAQEBAQEBZCeCMYJEgQsCJgJfiEcBCaBEj2KQTQsBAQEBHQWBAYQugm+KFyuCLwWYcQGBMIRUiCSJQYVhj3MCHjaDcopnAQEB X-IronPort-AV: E=Sophos;i="5.26,484,1459807200"; d="scan'208";a="222900833" Received: from wanjo.de (HELO zulu1878.startdedicated.de) ([62.75.236.16]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2016 20:09:43 +0200 Received: from localhost (fuenf.wanjo.de.local [127.0.0.1]) by zulu1878.startdedicated.de (Postfix) with ESMTP id 916964D837C5 for ; Fri, 17 Jun 2016 20:09:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at zulu1878.startdedicated.de Received: from zulu1878.startdedicated.de ([127.0.0.1]) by localhost (fuenf.wanjo.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDWHwSydiPzr for ; Fri, 17 Jun 2016 20:09:40 +0200 (CEST) Received: from martins-macbook-pro.fritz.box (x4e328939.dyn.telefonica.de [78.50.137.57]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zulu1878.startdedicated.de (Postfix) with ESMTPSA id 0438E4D8330D for ; Fri, 17 Jun 2016 20:09:39 +0200 (CEST) From: =?utf-8?Q?=22Martin_R=2E_Neuh=C3=A4u=C3=9Fer=22?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <7182303B-EBFF-4CFC-A7DF-B5C7A059509F@marneu.com> Date: Fri, 17 Jun 2016 20:09:38 +0200 To: OCaml List Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Subject: [Caml-list] Presumed bug in OCaml's garbage collector or in its Weak module... Dear all, after an intense week of debugging some large C-bindings, I presume to have= found a bug in OCaml=E2=80=99s garbage collection code or in its Weak modu= le.=20 To summarize, it seems as if OCaml=E2=80=99s garbage collector and its Weak= module sometimes release a custom block (by calling its finalizer) too ear= ly, i.e. when it is still reachable. I hesitate a bit before opening an =E2=80=9Eofficial=E2=80=9C issue on Mant= is as I might very well overlook some detail. Therefore I=E2=80=99d like to= double-check some of the assumptions that I have made when writing my C-st= ubs. Any corrections are highly welcome: 1. Custom blocks may be moved around in memory by the GC, but they are neve= r duplicated. 2. The finalizer for each custom block that is allocated by caml_alloc_cust= om is called at most once. 3. The finalizer is never called for blocks that are still alive; stated ot= herwise, a block that has been finalized can never been presented as a valu= e to a C-stub anymore. There is a small example program available on github: https://github.com/ma= rtin-neuhaeusser/ocaml_bug where the above assumptions seem to be violated. The idea is as follows: Each custom block that the example allocates contains a pointer to structur= e that is malloc=E2=80=99ed outside the OCaml heap; each custom block uniqu= ely refers to such a structure. Upon creation of a custom block, a special flag-value is stored in its corr= esponding (newly created) structure to indicate that the block is alive. On= ce a custom block=E2=80=99s finalizer is called, the flag is changed to ind= icate finalization of the block. I assume that after the finalizer returns,= the custom block is unreachable (and perhaps its memory reclaimed by the G= C); however, for debugging, I intentionally keep the custom block=E2=80=99s= structure allocated on the unmanaged heap. Whenever a custom block is pres= ented to the C-stubs, they check that the corresponding flag-value within i= ts corresponding non-managed heap structure indicates liveness of the block= . As it turns out, this invariant is violated, if the Weak module and the G= C are stressed. Of course, it might very well be that there is a bug in my C-stubs that is = responsible for that behavior. I tested with different versions of OCaml, w= ith different outcomes: The example program terminates correctly with OCaml= 3.12.1, 4.00.0, 4.00.1, 4.01.0, and 4.03.0+beta1 whereas it crashes due to= the above error when compiled with OCaml 4.02.0, 4.02.1, 4.02.2, 4.02.3, 4= .03.0+beta2, and the released 4.03.0. The tests were run on 64bit Debian Li= nux and 64bit MacOS X. I'd very much appreciate any help, hints to bugs in my code, or requests fo= r clarification. Thanks and best regards, Martin=