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

[Jeremy Yallop <yallop@gmail.com>]

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.