From: "Markus Weißmann" <markus.weissmann@in.tum.de>
To: <caml-list@inria.fr>
Cc: Gerd Stolpmann <info@gerd-stolpmann.de>
Subject: Re: [Caml-list] Obj.out_of_heap_tag, out of minor heap or memory corruption?
Date: Fri, 29 Apr 2016 16:14:07 +0200 [thread overview]
Message-ID: <5630123afc948279fc61d5e4c35d9014@in.tum.de> (raw)
In-Reply-To: <1461935860.9915.100.camel@e130.lan.sumadev.de>
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/
next prev parent reply other threads:[~2016-04-29 14:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-29 11:04 Markus Weißmann
2016-04-29 13:17 ` Gerd Stolpmann
2016-04-29 14:14 ` Markus Weißmann [this message]
2016-04-29 14:25 ` Gerd Stolpmann
2016-05-02 8:27 ` Sébastien Hinderer
2016-05-02 14:30 ` Gabriel Scherer
2016-05-03 15:59 ` Boris Yakobowski
2016-04-29 14:57 ` Mark Shinwell
2016-04-29 15:41 ` Markus Weißmann
2016-04-29 16:41 ` Adrien Nader
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5630123afc948279fc61d5e4c35d9014@in.tum.de \
--to=markus.weissmann@in.tum.de \
--cc=caml-list@inria.fr \
--cc=info@gerd-stolpmann.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox