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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 4AC587FACB for ; Sat, 6 Sep 2014 08:01:38 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of milanst@gmail.com) identity=pra; client-ip=209.85.223.171; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="milanst@gmail.com"; x-sender="milanst@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of milanst@gmail.com designates 209.85.223.171 as permitted sender) identity=mailfrom; client-ip=209.85.223.171; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="milanst@gmail.com"; x-sender="milanst@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ie0-f171.google.com) identity=helo; client-ip=209.85.223.171; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="milanst@gmail.com"; x-sender="postmaster@mail-ie0-f171.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIBAOiiClTRVd+rlGdsb2JhbABAGoNgVwSCeLAEliaHTAF8CBYQAQEBAQcLCwkSK4QEAQEEEhEEGQEbEgsBAwwGBQsNAgIJHQICIgERAQUBChIGExIQiAsBAxENNp05a4srgXKDEIh1ChknAwpmhXQBEQEFDoEejiEHgnmBUwWFCgWQX4I7hEOBXJFYGCmFLiEvAYJOAQEB X-IPAS-Result: AsIBAOiiClTRVd+rlGdsb2JhbABAGoNgVwSCeLAEliaHTAF8CBYQAQEBAQcLCwkSK4QEAQEEEhEEGQEbEgsBAwwGBQsNAgIJHQICIgERAQUBChIGExIQiAsBAxENNp05a4srgXKDEIh1ChknAwpmhXQBEQEFDoEejiEHgnmBUwWFCgWQX4I7hEOBXJFYGCmFLiEvAYJOAQEB X-IronPort-AV: E=Sophos;i="5.04,478,1406584800"; d="scan'208";a="77953212" Received: from mail-ie0-f171.google.com ([209.85.223.171]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 06 Sep 2014 08:01:22 +0200 Received: by mail-ie0-f171.google.com with SMTP id rp18so15244010iec.16 for ; Fri, 05 Sep 2014 23:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GcruxUFFDfqphD7HVSq5HKcTetT9ysiBqUWfbhdDewQ=; b=mPfcYMGhWj/nat7AmqmbTdDoIcdJwuoYj4GR4CjqNoh1qEHjSpAISGVVsDyhMjoRFf +yrc8BqzEfXPfTBXNSgS/aEmn+SKEE97CbRVLmltkEtOjx4k/1r6agST257biJNPW8pC aAmRsKwmpR50sNrVdyVUqzAd8o3vgoctrSQzA96c+zJO95f1nKTatQ/DKwk9QM/uPqAv T8Uj6BoF3Oj5330grP4aXltt1yMHpOX9QWsIOwsSR2botov6i+g68nP5GQn+j/Apns8O Ddf3TtGHGxeiAbs6PoAx25T9PYsWT6Nm7yTJ5UdADZbwhqPWdfwU8iQkNmoYp1eT/HMd xo1w== X-Received: by 10.43.158.195 with SMTP id lv3mr19781040icc.30.1409983280805; Fri, 05 Sep 2014 23:01:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.221.66 with HTTP; Fri, 5 Sep 2014 23:00:40 -0700 (PDT) In-Reply-To: <540AA0DB.1040202@ens-lyon.org> References: <20140905215626.GB3416@annexia.org> <20140905221302.GE3099@annexia.org> <20140905221813.GC3416@annexia.org> <540A3B85.6010609@ens-lyon.org> <540AA0DB.1040202@ens-lyon.org> From: =?UTF-8?Q?Milan_Stanojevi=C4=87?= Date: Sat, 6 Sep 2014 02:00:40 -0400 Message-ID: To: Martin Jambon Cc: Jeremy Yallop , Caml List Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] segfault in simple program with 4.02 native Could you do a dirty trick where you define a record that is the same as the one you have now except that is has mutable fields, then you do your parsing like now and then at the end return a record with immutable fields (using (Obj.magic mutable : immutable)? You just need to make sure that your mutable record doesn't escape your code. On Sat, Sep 6, 2014 at 1:51 AM, Martin Jambon wrote: > On Fri 05 Sep 2014 05:12:44 PM PDT, Jeremy Yallop wrote: >> >> 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. > > > Thanks for the explanation, Jeremy. I guess atdgen will have to use "option > refs" after all unless someone has a better idea. > > ATD definition: > > type t = { > ?field0: foo option; > ~field1: string; > field2: int; > } > > Generated OCaml code: > > let field0 = ref None in > let field1 = ref "" in > let field2 = ref None in > ... > (* parse json fields coming in an unknown order *) > ... > { > field0 = !field0; > field1 = !field1; > field2 = (match !field2 with None -> error ... | Some x - >x); > > } > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs