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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id D2B127EE89 for ; Fri, 29 Apr 2016 15:17:47 +0200 (CEST) IronPort-PHdr: 9a23:PpP5AhSLjLnLokQEGLNXKuSpENpsv+yvbD5Q0YIujvd0So/mwa64YhON2/xhgRfzUJnB7Loc0qyN4/CmCTJLvMnJmUtBWaIPfidNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV3BPAZ4bt74BpTVx5zukbviq9uDPU4V23KUWvBbElaflU3prM4YgI9veO4a6yDihT92QdlQ3n5iPlmJnhzxtY+a9Z9n9DlM6bp6r5YTGfayQ6NtaLVCDyk9e1845XruvB/FBV+K72EfT35QjRdJGBPA5Rf8dpb39Dfns6xx1X/JE9fxSOUbVC6up5x3TxvwjS4BMXZt8WfZjeR/gbhX5Qm9oBhnxofSZseZOawtLevmYdoGSD8ZDY5qXCtbD9bkYg== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=info@gerd-stolpmann.de; spf=None smtp.mailfrom=info@gerd-stolpmann.de; spf=None smtp.helo=postmaster@mout.kundenserver.de Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=217.72.192.74; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=217.72.192.74; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.kundenserver.de) identity=helo; client-ip=217.72.192.74; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@mout.kundenserver.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BIAABoXiNXj0rASNldhAt9sh6HYYF2FweFcQKBKjoSAQEBAQEBAQERAQEBAQcLCwkhL4ItghUBAQMBVSQFCwtGVwYTCYgZDAEJxA4BAQEBAQUBAQEBFAiFKYVEhCcigjwLQIJDBYd2kB2BNAKHPYUkgjWHAQSFV0WOaycJgjcRCoFNagGJAAEBAQ X-IPAS-Result: A0BIAABoXiNXj0rASNldhAt9sh6HYYF2FweFcQKBKjoSAQEBAQEBAQERAQEBAQcLCwkhL4ItghUBAQMBVSQFCwtGVwYTCYgZDAEJxA4BAQEBAQUBAQEBFAiFKYVEhCcigjwLQIJDBYd2kB2BNAKHPYUkgjWHAQSFV0WOaycJgjcRCoFNagGJAAEBAQ X-IronPort-AV: E=Sophos;i="5.24,551,1454972400"; d="asc'?scan'208";a="176214680" Received: from mout.kundenserver.de ([217.72.192.74]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 15:17:46 +0200 Received: from office1.lan.sumadev.de ([188.107.80.127]) by mrelayeu.kundenserver.de (mreue104) with ESMTPSA (Nemesis) id 0McEqN-1bDvry3zE7-00JbyV; Fri, 29 Apr 2016 15:17:46 +0200 Received: from [192.168.65.10] (unknown [192.168.65.10]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 2CBBCDC05D; Fri, 29 Apr 2016 15:17:45 +0200 (CEST) Message-ID: <1461935860.9915.100.camel@e130.lan.sumadev.de> From: Gerd Stolpmann To: Markus =?ISO-8859-1?Q?Wei=DFmann?= Cc: caml-list@inria.fr Date: Fri, 29 Apr 2016 15:17:40 +0200 In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-/yoFLuiy0BieVoQPn/6D" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 X-Provags-ID: V03:K0:rzpLNKTQvItrGgHm1ZwoFthI4O679gudm4wx2pR7H8L39H5z0nz J6wAOGj9NsOCCGsUDLuNzI5KrYQDInQ7r1zVyHrHaXLAtrM92YwvojCD71CXIl0DmMDqM1r AAWPhpv1k4XSwjW2vn0eU//Q3Yz297o07qiNhrI2NyTEK8Ls7KlyzJZ/XZahfYg2UuB2779 5Og1kina77PqDKyPFBpBg== X-UI-Out-Filterresults: notjunk:1;V01:K0:nbegNKMGusk=:lbg0NZ+T5tePM36a95rEwn yyzkx04iCWMMgMKeElfrrqxQUhrIYSlLEwx2LEw73Uwyvwak1gWsaJHBddFQqF6FfOWCLqL/D UsvppHx4cCUn8yLI1KcFN8VTI+aIOPGYjPAhoCgspP8gb7zMNIp6qZbRY7PU6CdB57bwLUFq7 mfnuXCLUzVM1S+XWUYkfucCLFKzpquqbV2nPyriV4T1oe9cuE6GFFJw8xAU9CoV2w3oXOjui2 sIINFWVAPOrb09UI/7sUyjPd7SYz25agpT77+fLUFV+hLgtvGFNPOHFkHOBf6sVaHnZJxD6aO HmNaqxVoC1WTwxS0g3Z5xVzI5J2NUtwY0yf26P+P7OAWstc2qOc8au5+doB/4NI9ww2UY3Nv6 /kG+7/7Tia18DrMSJLqTdgnN+yNsQ9O0TkuuDSGfvsuCIfM3Gjm2zVX+0EhaII/Ccw9JkB7OX j3PYIOx0punt/eikZoJ6wPVmivj4UeMtWTjOBUk35BLVuh1pM0YJWqiPCsczKueJBLQ9wJMWG hoQETYrC8gI4tC07UyZbCYGl7YKfYikhF3bDPSwd/5O7/umu4fzDzzcVbcKYD2PhLmLvC6LLr D/+abs55oafVrGvM13iYcOB9z3lAkd0vUdqw1gv+3UgFZDJS6EDkNRQPdesZGiOL6RKhU+F8M AXcz8PyFxVP6h3vuMwpvgmLuan/lOUGAxcczKUFkSFfUS0b+EhLzw+DkHfwF1RPBazyo= Subject: Re: [Caml-list] Obj.out_of_heap_tag, out of minor heap or memory corruption? --=-/yoFLuiy0BieVoQPn/6D Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Am Freitag, den 29.04.2016, 13:04 +0200 schrieb Markus Wei=DFmann: > Hello, >=20 > I have a server program that crashes after some time with a very=20 > strange error: > The (=3D) comparison of two values returns false, even though they are=20 > pretty identical. > They are of type { a : int; b : int } and the comparison always fails=20 > on the second integer. > When printing the compared integers, they are always 0 (as expected) --=20 > both of them; but are not equal (=3D). > I started inspecting the values with the "Obj.tag" and found them to be=20 > 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=20 > value surprisingly behaved like an integer unless compared to another: >=20 > let (x : int) =3D > print_int x; (* "0" *) > assert (x =3D 0) (* fails! *) >=20 > Can someone explain what this tag means exactly and if this=20 > works-as-intended or if my heap must have gotten hit by some faulty C=20 > 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=3D1000 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=20 > Gc.minor_heap_size to 4 MByte I don't get the Obj.out_of_heap_tag -- or=20 > at least haven't yet. >=20 > This is ocaml 4.02.3 on amd64. >=20 > Regards > Markus >=20 > --=20 > Markus Wei=DFmann, M.Sc. > Technische Universit=E4t M=FCnchen > Institut f=FCr Informatik > Boltzmannstr. 3 > D-85748 Garching > Germany > http://wwwknoll.in.tum.de/ >=20 >=20 --=20 ------------------------------------------------------------ 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 ------------------------------------------------------------ --=-/yoFLuiy0BieVoQPn/6D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJXI170AAoJEAaM4b9ZLB5T3GcH/3xQaLv18i09YA1hDFxUrEqD CZbQVma3fDo8g7/hWdknaVGA4qUP0eu7N6PMB1UpVZvA+v4z1y2gcJZwuDYH66ds Vmv/WEQfemjmeKPOZva49X9xPETbZOeQMkYbstNBE1F5MuIxF/AlNQMcuoMCuxjv 9tdyFu3NZnRe8Y4aMuL7bincT+Nn2MWuoXUStVr8K2HByj/zOu2SOps20cpXx7eJ Y9l3hsP5CzP9yP9xnZRHzjClcCiXwIZU4eYZtPFyNJdXI/DqR6P/gCiFTos2Whb5 X0E32N/d6DLJcUxDTOAmPos8E9Wjumem895S6lM/6w+K8a/wkmYEHkx1nc3cZsI= =AaHu -----END PGP SIGNATURE----- --=-/yoFLuiy0BieVoQPn/6D--