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 8B2817FACB for ; Sat, 6 Sep 2014 02:12:45 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yallop@gmail.com) identity=pra; client-ip=209.85.212.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yallop@gmail.com"; x-sender="yallop@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yallop@gmail.com designates 209.85.212.178 as permitted sender) identity=mailfrom; client-ip=209.85.212.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yallop@gmail.com"; x-sender="yallop@gmail.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@mail-wi0-f178.google.com) identity=helo; client-ip=209.85.212.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yallop@gmail.com"; x-sender="postmaster@mail-wi0-f178.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEBAB1RClTRVdSylGdsb2JhbABAGoNgVwSCeMYkh0wBfAgWEAEBAQEHCwsJEiuEBAEBBBIRHQEbHQEDDAYFCw0CAiYCAiIBEQEFARwGEyKICwEDEQ02nTRriyuBcoMQiQEKGScNZoV0AREBBQ6BHo4hB4J5gVMFlW6GfoFckVgYKYUUOy8Bgk4BAQE X-IPAS-Result: AsEBAB1RClTRVdSylGdsb2JhbABAGoNgVwSCeMYkh0wBfAgWEAEBAQEHCwsJEiuEBAEBBBIRHQEbHQEDDAYFCw0CAiYCAiIBEQEFARwGEyKICwEDEQ02nTRriyuBcoMQiQEKGScNZoV0AREBBQ6BHo4hB4J5gVMFlW6GfoFckVgYKYUUOy8Bgk4BAQE X-IronPort-AV: E=Sophos;i="5.04,476,1406584800"; d="scan'208";a="93263842" Received: from mail-wi0-f178.google.com ([209.85.212.178]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 06 Sep 2014 02:12:45 +0200 Received: by mail-wi0-f178.google.com with SMTP id n3so8264wiv.11 for ; Fri, 05 Sep 2014 17:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TD4e9mywcebnVwQZxfd8q1uDwsxHOaQaRJu8WCnDxqg=; b=aUUXjacKBwckBYZSUbGS0g4mXyDWizPqw2Er615V7O0O2VQ76vN1Xmer5BFn6CroX2 LUhaIfvDECzJEViON5iFJyAXXX3tn5r7C4XwJekLnramqzzR5Mk2evNGkY5UtGBR3Egy m5NFpT0tho0lfR/E+b944OQwjb9bpo/xOWhDdHSqfq/0YIBQFxJ20ijv+vvZpTSX++t0 rGEmtBN5hVZ0sPuA1e+N96mNvkbSPa4x0vDyYLa3wH9JMPPAFl95jac53bt3yiVkn83V Tgv+NbmrV6qxk1EBeiOUe/kOekj0hPP7mf+HmUu0mhfwal36A/BZz7+y1mexZquDVYqF wsBQ== MIME-Version: 1.0 X-Received: by 10.194.63.205 with SMTP id i13mr18263645wjs.74.1409962364658; Fri, 05 Sep 2014 17:12:44 -0700 (PDT) Received: by 10.217.131.18 with HTTP; Fri, 5 Sep 2014 17:12:44 -0700 (PDT) In-Reply-To: <540A3B85.6010609@ens-lyon.org> References: <20140905215626.GB3416@annexia.org> <20140905221302.GE3099@annexia.org> <20140905221813.GC3416@annexia.org> <540A3B85.6010609@ens-lyon.org> Date: Sat, 6 Sep 2014 02:12:44 +0200 Message-ID: From: Jeremy Yallop To: Martin Jambon Cc: Caml List Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] segfault in simple program with 4.02 native On 6 September 2014 00:39, Martin Jambon wrote: > That code is generated by atdgen. What happens is that we have to either > create an empty record when starting to parse a list of unordered JSON > fields, or use a bunch `let = ref None in` for each field and > create the record in the end. While the latter approach is not much more > work to implement, the resulting code was found to be significantly slower. > > The reason why it's using `Obj.magic 0.0` is that it worked in all cases > (and has been for the past 4 years). Obtaining a well-formed constant value > for any type is not trivial, so this what we have. > > It's very possible that it's now broken with OCaml 4.02. First try a 'make > test' from atdgen's source directory (https://github.com/mjambon/atdgen) and > see if it passes. It does seem to be broken, and the change in behaviour with 4.0.2 is apparently due to improved constant propagation (http://caml.inria.fr/mantis/view.php?id=5779). The compiler now takes more advantage of immutability to improve the memory usage and performance of programs. It's safe (or ought to be safe) to assume that immutable record fields are never updated, so the values used to initialize the fields can be propagated to other parts of the program. Here's a small example that shows the change in behaviour between 4.01 and 4.02. type t = { s : string } let x = { s = "one" } let () = Obj.(set_field (repr x) 0 (repr "two")) let () = print_endline x.s Using OCaml 4.01 the third line overwrites the field 's' and the fourth line reads the updated field and prints "two". Using OCaml 4.02 the initial value of the field is propagated past the write to the code in the fourth line, so the program prints "one". The code currently generated by atdgen assumes that it's safe to treat fields as if they were mutable -- that is, it assumes that it's safe to initialize a field with a value of the wrong type, so long as the value is overwritten before the field is first read. I don't think such tricks were ever explicitly guaranteed to work, but they're now much more likely to fail, leading to the dummy initial value being accessed at an inappropriate type.