From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 0E5E67EE88 for ; Fri, 29 Apr 2016 16:25:25 +0200 (CEST) IronPort-PHdr: 9a23:N35MiBX31HnK3pBf1K8Gkux2l1/V8LGtZVwlr6E/grcLSJyIuqrYZhKAt8tkgFKBZ4jH8fUM07OQ6PCwHzxeqsnb+Fk5M7VyFDY9wf0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3CwN5K6zPF5LIiIzvjqbpq82VM1sD22D1SIgxBSv1hD2ZjtMRj4pmJ/R54TryiVwMRd5rw3h1L0mYhRf265T41pdi9yNNp6BprJYYAu2pN5g/GJlRFjc7KCgK6cxcsBDFS0Pb43IGUXgN1AVFAhPe6Rj8WL/wtG3mq+871CTMbuPsSrVhdjm44+9QVBjskCIOMThxpGDRhMtYg69BrFe6uxt724vdZofTOPcoLfCVRs8TWWcUBpUZbCdGGI7pN4Y= 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=212.227.126.131; 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=212.227.126.131; 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=212.227.126.131; 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: A0BeAACnbSNXj4N+49RdhAt9sh6JVxcHhXICgSo7EQEBAQEBAQEBEQEBAQEHCwsJIS+CLYIVAQEDAVUkEAtGVwYTCYgZDAEJxBgBAQEBAQUBAQEBFAiFKYVEhEmCPAtAgkMFh3aQHYE0AoxhgjWHAQSFV0WOazaCQoFXagGJAAEBAQ X-IPAS-Result: A0BeAACnbSNXj4N+49RdhAt9sh6JVxcHhXICgSo7EQEBAQEBAQEBEQEBAQEHCwsJIS+CLYIVAQEDAVUkEAtGVwYTCYgZDAEJxBgBAQEBAQUBAQEBFAiFKYVEhEmCPAtAgkMFh3aQHYE0AoxhgjWHAQSFV0WOazaCQoFXagGJAAEBAQ X-IronPort-AV: E=Sophos;i="5.24,552,1454972400"; d="asc'?scan'208";a="176227286" Received: from mout.kundenserver.de ([212.227.126.131]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 16:25:24 +0200 Received: from office1.lan.sumadev.de ([188.107.80.127]) by mrelayeu.kundenserver.de (mreue001) with ESMTPSA (Nemesis) id 0MFlnp-1asYSd2s5t-00Ebon; Fri, 29 Apr 2016 16:25:22 +0200 Received: from [192.168.65.10] (unknown [192.168.65.10]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 25D5CDC05D; Fri, 29 Apr 2016 16:25:22 +0200 (CEST) Message-ID: <1461939917.9915.110.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 16:25:17 +0200 In-Reply-To: <5630123afc948279fc61d5e4c35d9014@in.tum.de> References: <1461935860.9915.100.camel@e130.lan.sumadev.de> <5630123afc948279fc61d5e4c35d9014@in.tum.de> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-NF/Ki8qTTlmwY1yX5cX8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 X-Provags-ID: V03:K0:qFeOrrZPd+9cb1n1tQk2ME6jwXQmqXGvUiccGz8geF2mArLcF2G 2sOlxDTXicxrzrrRpyc0R8JmYM4Si7qBzRE7hJiUGYlhF6OfqUiysSx4aorln0Sjg7Bq460 jsgmmRWUs+dnDla/KW9ALgAy65bc4CehbxgkL1UoF17Gsgq+NrTaO4lHr+Zq2UT/nCbwLB6 IsR4J95UHY6xBD9UBadiQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Dgd8AOvqXs0=:MCxpxEpyfNJcJcHQvj6VIq EMdnZiKd9tKrbXLWvnw0pFy/JCfq14dgtGPXfa8t6lFA182E+TLTMB4u+ivy451Er56i3SrOa K+KAto6h3cY278rJ3uaGccBRjuby3xRs6l5/NmkF4WDzBFoAisoCvwYWeJWalqBBW3IgsqApM r0JqUZ2sS/6SQFGZsVW9WZDW8xwLUiNfgkZIR8228PithRCyOGrgr/2T9ExdUk9QldN0aGUT5 e7HMuagIKNnAJH8gadp8IuyfcDTxATqJyAWGfGAPjzrXexWPd0Ke2XNt2I/w+ot23ZzEpuYNN XJKOxgSi8n8AsR4PXJABW76oatnposdcdec0ecTMZx9HZCxYIAlEYjK14/wGpqs7nRlzS/sf5 +gyEQK8sH2JJmj8SjIRdsqgmdt9jqvBxtoOCY/4Gngz0mGppBD6K+r0teKaJED1giLt3KvD3X +mYJmHl/VkEyEgfjXI6sH0HMupVrLWo+89GldWPTxCXX9rFJLo27yy5d0tscBsj6it90geoiH SmpveWT5pHSP9ab4mYhg5+cO243SDDHsbP9pAm2kP/vE04xUubmLTJMIUJ00B2s4UP0aMHGf7 9GYHhiQeoMrwT2GMfwrUb17axvxHzCf8YwQ3lQpEDunC7m0o6tLDZIDJwXa2JHzQw7gwM4Jyf vvXbWKghiauxV1u/w07sEiPV53IA8KRrrSVhtKlfQBx9+bwfsmc2ItSD+2LpnnwAqJnk= Subject: Re: [Caml-list] Obj.out_of_heap_tag, out of minor heap or memory corruption? --=-NF/Ki8qTTlmwY1yX5cX8 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Am Freitag, den 29.04.2016, 16:14 +0200 schrieb Markus Wei=DFmann: > 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: Well, there are other types of errors in C bindings that could also cause this. Imagine what happens when the C bindings do not properly handle pointers (e.g. do not declare them as local roots), and an outdated pointer to an int is followed by the GC because of this. Because the minor GC moves values to the major heap, this could cause that the int is overwritten then. In my experience, it's always the C binding! Unfortunately, there's no code for investigations. Gerd >=20 > type foo =3D { a : int; b : int } >=20 > let create (a : int) (b : int) =3D > assert (Obj.is_int (Obj.repr x)); (* always holds *) > { a; b } >=20 > This assertion never triggered so far. > I replaced the equality check by a function which now also asserts the > is_int property: >=20 > let equal (x : foo) (y : foo) =3D (* y is a static value living throug= h=20 > 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=20 > *) > assert (Obj.is_int (Obj.repr y.b)); > x =3D y >=20 > and one of these (always the same) triggers after a while (after some=20 > 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,=20 > put through > the constructor function, compared and thrown away. >=20 > Regards > Markus >=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 ------------------------------------------------------------ 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 ------------------------------------------------------------ --=-NF/Ki8qTTlmwY1yX5cX8 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 iQEcBAABAgAGBQJXI27NAAoJEAaM4b9ZLB5T7GAIAI8qQZSj4/YKrJkB13/8wqOH fNjZ6wef9S9BgsF6TPaDUNFwc47NUC4Wclv2f/YxXr1AuUuw38d/HVXat2Zy1P/6 H04S87pCR3J++agKLkqW785ujzk/pLQJcWyqQ1nEX7NzFTv0k0XJH/qWJYLD2BLV TLSNx1FjOA25ypBRbN4G/uizEIl1qg1QYEn5IDx6H5olh1vTDUxaVV0ikwG8k5Vp 5a8PhgwLm2xw/h54WtzqNhneZ20clSy2lp0iVCrZHNBYqnwUC2ya1vuDRVVHOsy7 ysopM6k0QSTH+DTRnxxHAEATcrtHEI/8PCU93D9Dc2E2bQYIEXcjkWeELZu4Dlc= =Cpnx -----END PGP SIGNATURE----- --=-NF/Ki8qTTlmwY1yX5cX8--