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 AC4BC7EE88 for ; Fri, 29 Apr 2016 17:41:19 +0200 (CEST) IronPort-PHdr: 9a23:ck6a3hcet4T+RtPHg3iC0F3zlGMj4u6mDksu8pMizoh2WeGdxc6ybR7h7PlgxGXEQZ/co6odzbGG4+awBydQvd6oizMrTt9lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUiv2OQc9HOnpAIma153xjLDivc2NKFUUzBOGIppMbzyO5T3LsccXhYYwYo0Q8TDu5kVyRuJN2GlzLkiSlRuvru25/Zpk7jgC86l5r50IeezAcq85Vb1VCig9eyBwvZWz9Er1dhaU/nYXTkkRlxNJBUCFsEC7Dd/NtX6uveN43GyePNbqZbEyQzWrqalxHkzGkiACYhsw6mLKkftPgaPspRunoVQrxofOY5yOcuVzf7jGeNocQ0JAWIBNSikHDo7qPNhHNPYIIesN99q1nFAJtxbrQFT1CQ== Authentication-Results: mail3-smtp-sop.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 (mail3-smtp-sop.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=mail3-smtp-sop.national.inria.fr; envelope-from="markus.weissmann@in.tum.de"; x-sender="markus.weissmann@in.tum.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.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=mail3-smtp-sop.national.inria.fr; envelope-from="markus.weissmann@in.tum.de"; x-sender="markus.weissmann@in.tum.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.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=mail3-smtp-sop.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: A0CFAAA0fyNXkAgAn4NdhAt9AakNkmcihW4CgSo8EAEBAQEBAQEBEQEBAQEHDQkJIS+CLYIUAQEBAwEjDwEFNgsQBAcYAgIJHQICRRIGEwgKiAMDCggOszqMRAOEWAEBAQEGAQEBAQEBGnyJcYQnFoMAglYFhjUMkVKFfIJ3hR2CPIcBhVtFjms3gjARCoFNOjCJAQEBAQ X-IPAS-Result: A0CFAAA0fyNXkAgAn4NdhAt9AakNkmcihW4CgSo8EAEBAQEBAQEBEQEBAQEHDQkJIS+CLYIUAQEBAwEjDwEFNgsQBAcYAgIJHQICRRIGEwgKiAMDCggOszqMRAOEWAEBAQEGAQEBAQEBGnyJcYQnFoMAglYFhjUMkVKFfIJ3hR2CPIcBhVtFjms3gjARCoFNOjCJAQEBAQ X-IronPort-AV: E=Sophos;i="5.24,552,1454972400"; d="scan'208";a="176237084" Received: from mail-out1.informatik.tu-muenchen.de ([131.159.0.8]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-GCM-SHA384; 29 Apr 2016 17:41:18 +0200 Received: from webmail.in.tum.de (localhost [127.0.0.1]) by vmwebmail1.informatik.tu-muenchen.de (Postfix) with ESMTP id C5C5D2403AE; Fri, 29 Apr 2016 17:41:17 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 29 Apr 2016 17:41:17 +0200 From: =?UTF-8?Q?Markus_Wei=C3=9Fmann?= To: Cc: Gerd Stolpmann , Mark Shinwell In-Reply-To: References: <1461935860.9915.100.camel@e130.lan.sumadev.de> <5630123afc948279fc61d5e4c35d9014@in.tum.de> Message-ID: 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? Thanks a lot Gerd and Mark: It was in the C code: A missing CAMLlocal(). =) The funny thing was: It had _nothing_ to do with the piece of code the bug surfaced around. So for anyone reading this thread in the future, tearing your hair out in frustration: Check your C code. I hereby confirm the Stolpmann-Theorem: "Its always the C code." regards Markus On 2016-04-29 16:57, Mark Shinwell wrote: > It may be worth printing the pointer at the time of allocation of > this > record, and then at the time just before the assertion fails. I > think > you can just Obj.magic the record to "int" (use printf and %d) and > then when you see the answer on the screen, multiply it by 2 to get > the correct pointer. Or send it back to a C binding and printf it > from there. Anyway, this might help to diagnose whether the value > was > moved between the allocation and the failure; it seems likely it was. > If so it's probably a missing CAMLlocal or similar. > > The thing about it being very sensitive to the heap size is > characteristic of that kind of bug. You're effectively relying on a > particular allocation triggering a GC, so the heap has to be full at > just the right time. > > Another technique that can be useful for diagnosing heap corruption > is > gdb watchpoints on the part of the value concerned. > > Mark > > On 29 April 2016 at 15:14, Markus Weißmann > wrote: >> 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/ >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs -- 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/