Re: [Caml-list] segfault in simple program with 4.02 native

[Martin Jambon <martin.jambon@ens-lyon.org>]

On Fri 05 Sep 2014 05:12:44 PM PDT, Jeremy Yallop wrote:
> On 6 September 2014 00:39, Martin Jambon <martin.jambon@ens-lyon.org> 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 <field name> = 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);
}