Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: "Markus Weißmann" <markus.weissmann@in.tum.de>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Obj.out_of_heap_tag, out of minor heap or memory corruption?
Date: Fri, 29 Apr 2016 15:17:40 +0200	[thread overview]
Message-ID: <1461935860.9915.100.camel@e130.lan.sumadev.de> (raw)
In-Reply-To: <daef7ec24e2696f048cbd4fb10311cba@in.tum.de>

[-- Attachment #1: Type: text/plain, Size: 2348 bytes --]

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.

Actually, I wonder what Obj.int_tag=1000 is for. It's not something that
can really occur, because tags are 8 bits wide. Maybe it's a replacement
when Obj.tag is called for non-blocks?

Gerd


> Is this some out-of-memory handling of the minor heap? If I set 
> Gc.minor_heap_size to 4 MByte I don't get the Obj.out_of_heap_tag -- or 
> at least haven't yet.
> 
> This is ocaml 4.02.3 on amd64.
> 
> 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/
> 
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2016-04-29 13:17 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 [this message]
2016-04-29 14:14   ` Markus Weißmann
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=1461935860.9915.100.camel@e130.lan.sumadev.de \
    --to=info@gerd-stolpmann.de \
    --cc=caml-list@inria.fr \
    --cc=markus.weissmann@in.tum.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