From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 35B0F7EE88 for ; Fri, 29 Apr 2016 16:14:09 +0200 (CEST) IronPort-PHdr: 9a23:d7MqUxceICo8VV771bjD+YuylGMj4u6mDksu8pMizoh2WeGdxc6+bB7h7PlgxGXEQZ/co6odzbGG4+awBydev96oizMrTt9lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUiv2OQc9HOnpAIma153xjLDivc2NKFsWzBOGIppMbzyO5T3LsccXhYYwYo0Q8TDu5kVyRuJN2GlzLkiSlRuvru25/Zpk7jgC86l5r50IAu3GePFsRrVdCHEiMnspzMztrxjKCwWVsCgySGITxz9BGQvY9ybFU5ZGtyL8sKIp3SCAPtDtC685WC+56q5tTjfpjmEbKjt//GyB2Z84t75SvB/0/083+IXTeozAbPc= Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=markus.weissmann@in.tum.de; spf=None smtp.mailfrom=markus.weissmann@in.tum.de; spf=None smtp.helo=postmaster@mail-out1.informatik.tu-muenchen.de Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of markus.weissmann@in.tum.de) identity=pra; client-ip=131.159.0.8; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.weissmann@in.tum.de"; x-sender="markus.weissmann@in.tum.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of markus.weissmann@in.tum.de) identity=mailfrom; client-ip=131.159.0.8; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.weissmann@in.tum.de"; x-sender="markus.weissmann@in.tum.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-out1.informatik.tu-muenchen.de) identity=helo; client-ip=131.159.0.8; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.weissmann@in.tum.de"; x-sender="postmaster@mail-out1.informatik.tu-muenchen.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BIAAANayNXkAgAn4NdhAt9u3UehXECgSk8EAEBAQEBAQEBEQEBAQEHDQkJIS+CLYIVAQEEIw8BBUEQBAcYAgImAgJXBhuIIrMdkSMBAQEHAQEBARx8iXGEJxZMgjSCVgWYE4hzhR2CPIcBhVtFjms3gjARCoFNOjCJAQEBAQ X-IPAS-Result: A0BIAAANayNXkAgAn4NdhAt9u3UehXECgSk8EAEBAQEBAQEBEQEBAQEHDQkJIS+CLYIVAQEEIw8BBUEQBAcYAgImAgJXBhuIIrMdkSMBAQEHAQEBARx8iXGEJxZMgjSCVgWYE4hzhR2CPIcBhVtFjms3gjARCoFNOjCJAQEBAQ X-IronPort-AV: E=Sophos;i="5.24,551,1454972400"; d="scan'208";a="216374177" Received: from mail-out1.informatik.tu-muenchen.de ([131.159.0.8]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-GCM-SHA384; 29 Apr 2016 16:14:08 +0200 Received: from webmail.in.tum.de (localhost [127.0.0.1]) by vmwebmail1.informatik.tu-muenchen.de (Postfix) with ESMTP id F31D0240476; Fri, 29 Apr 2016 16:14:07 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 29 Apr 2016 16:14:07 +0200 From: =?UTF-8?Q?Markus_Wei=C3=9Fmann?= To: Cc: Gerd Stolpmann In-Reply-To: <1461935860.9915.100.camel@e130.lan.sumadev.de> References: <1461935860.9915.100.camel@e130.lan.sumadev.de> Message-ID: <5630123afc948279fc61d5e4c35d9014@in.tum.de> X-Sender: markus.weissmann@in.tum.de User-Agent: Roundcube Webmail/0.8.1 Subject: Re: [Caml-list] Obj.out_of_heap_tag, out of minor heap or memory corruption? 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/