Re: [Caml-list] Obj.out_of_heap_tag, out of minor heap or memory corruption?

[Mark Shinwell <mshinwell@janestreet.com>]

It may be worth printing the pointer at the time of allocation of this
record, and then at the time just before the assertion fails.  I think
you can just Obj.magic the record to "int" (use printf and %d) and
then when you see the answer on the screen, multiply it by 2 to get
the correct pointer.  Or send it back to a C binding and printf it
from there.  Anyway, this might help to diagnose whether the value was
moved between the allocation and the failure; it seems likely it was.
If so it's probably a missing CAMLlocal or similar.

The thing about it being very sensitive to the heap size is
characteristic of that kind of bug.  You're effectively relying on a
particular allocation triggering a GC, so the heap has to be full at
just the right time.

Another technique that can be useful for diagnosing heap corruption is
gdb watchpoints on the part of the value concerned.

Mark

On 29 April 2016 at 15:14, Markus Weißmann <markus.weissmann@in.tum.de> wrote:
> On 2016-04-29 15:17, Gerd Stolpmann wrote:
>>
>> Am Freitag, den 29.04.2016, 13:04 +0200 schrieb Markus Weißmann:
>>>
>>> Hello,
>>>
>>> I have a server program that crashes after some time with a very
>>> strange error:
>>> The (=) comparison of two values returns false, even though they are
>>> pretty identical.
>>> They are of type { a : int; b : int } and the comparison always fails
>>> on the second integer.
>>> When printing the compared integers, they are always 0 (as expected) --
>>> both of them; but are not equal (=).
>>> I started inspecting the values with the "Obj.tag" and found them to be
>>> always of type Obj.int_tag -- until the non-equalness strikes:
>>> One of the compared integers then always has Obj.out_of_heap_tag. This
>>> value surprisingly behaved like an integer unless compared to another:
>>>
>>> let (x : int) =
>>>    print_int x; (* "0" *)
>>>    assert (x = 0) (* fails! *)
>>>
>>> Can someone explain what this tag means exactly and if this
>>> works-as-intended or if my heap must have gotten hit by some faulty C
>>> bindings?
>>
>>
>> Obj.tag is meaningless for ints.
>>
>> What could have happened is that a C lib did not set the LSB of the word
>> (which is required for ints in order to make them distinguishable from
>> pointers). The C lib MUST use Val_int or Val_long to create the values
>> (and these macros set the LSB).
>>
>> Check whether Obj.is_int returns true. If not, something is wrong.
>>
>
> The value comes from C bindings, but from a string-value via Char.code.
> It is then passed through a constructor-function to create the record;
> I added a check there to see if the C bindings are to blame:
>
>   type foo = { a : int; b : int }
>
>   let create (a : int) (b : int) =
>     assert (Obj.is_int (Obj.repr x)); (* always holds *)
>     { a; b }
>
> This assertion never triggered so far.
> I replaced the equality check by a function which now also asserts the
> is_int property:
>
>   let equal (x : foo) (y : foo) = (* y is a static value living through the
> entire run; x is from a parse/allocate/compare/throw-away cycle *)
>     assert (Obj.is_int (Obj.repr x.a));
>     assert (Obj.is_int (Obj.repr y.a));
>     assert (Obj.is_int (Obj.repr x.b)); (* <- this fails after a while *)
>     assert (Obj.is_int (Obj.repr y.b));
>     x = y
>
> and one of these (always the same) triggers after a while (after some 10.000
> calls).
> But only with the standard minor heap size, not with a 4 MB sized one.
> There are no other functions working on these values; they are parsed, put
> through
> the constructor function, compared and thrown away.
>
> Regards
> Markus
>
> --
> Markus Weißmann, M.Sc.
> Technische Universität München
> Institut für Informatik
> Boltzmannstr. 3
> D-85748 Garching
> Germany
> http://wwwknoll.in.tum.de/
>
> --
> 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