From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 C321A7EE88 for ; Fri, 29 Apr 2016 16:57:05 +0200 (CEST) IronPort-PHdr: 9a23:duPX0hxN9I58Ww7XCy+O+j09IxM/srCxBDY+r6Qd0eIeIJqq85mqBkHD//Il1AaPBtWLraIawLWM+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuSt6U35r8iLr60qaQSjsLrQL1Wal1IhSyoFeZnegtqqwmFJwMzADUqGBDYeVcyDAgD1uSmxHh+pX4p8Y7oGxmgO8678NLTYn9eq05S/QYUGVnYCgJ45jOvAPAUBC42XYd5WAflBwAVw3M9hLnRdHuvyrhre903i+yPMuwUa0xHzivufRFUhjt3QIOLT1xy2HWjNN9iKYT9Be6px153IPQZKmXPfxzZb/HcN4GA2FGW5ACBGR6HoqgYt5XXKI6NuFCotyh9lY= Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=mshinwell@janestreet.com; spf=Pass smtp.mailfrom=mshinwell@janestreet.com; spf=None smtp.helo=postmaster@mxout3.mail.janestreet.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of mshinwell@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mshinwell@janestreet.com"; x-sender="mshinwell@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of mshinwell@janestreet.com designates 38.105.200.229 as permitted sender) identity=mailfrom; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mshinwell@janestreet.com"; x-sender="mshinwell@janestreet.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mxout3.mail.janestreet.com) identity=helo; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mshinwell@janestreet.com"; x-sender="postmaster@mxout3.mail.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BfAACddSNXiuXIaSZdhAt9BqkIkmcihW4CgSMHPBABAQEBAQEBAREBAQEIFglQgi2CFQEBBBIRHQEBLAsBDwsLDQICCR0CAiISAQUBChIGEwgKEIdzAxIDC6VDgTE+MYpUZ4RBAQSIAgOERAEBAQEBAQEBAgEBAQEBAQEBAREGCnKFJYRMhCcWgwCCVoY6DJFShXyCd4UkgjWMXEWNLRIegQ43giMNEQqBTGuJAQEBAQ X-IPAS-Result: A0BfAACddSNXiuXIaSZdhAt9BqkIkmcihW4CgSMHPBABAQEBAQEBAREBAQEIFglQgi2CFQEBBBIRHQEBLAsBDwsLDQICCR0CAiISAQUBChIGEwgKEIdzAxIDC6VDgTE+MYpUZ4RBAQSIAgOERAEBAQEBAQEBAgEBAQEBAQEBAREGCnKFJYRMhCcWgwCCVoY6DJFShXyCd4UkgjWMXEWNLRIegQ43giMNEQqBTGuJAQEBAQ X-IronPort-AV: E=Sophos;i="5.24,552,1454972400"; d="scan'208";a="216381922" Received: from mxout3.mail.janestreet.com ([38.105.200.229]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 16:57:04 +0200 Received: from tot-qpr-mailcore1.delacy.com ([172.27.56.68] helo=tot-qpr-mailcore1) by mxout3.mail.janestreet.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1aw9qp-0002l7-F7 for caml-list@inria.fr; Fri, 29 Apr 2016 10:57:03 -0400 X-JS-Flow: external Received: by tot-qpr-mailcore1 with JS-mailcore (0.1) (envelope-from ) id BXI3Y_-AAADOl-NR; 2016-04-29 10:57:03.426037-04:00 Received: from mail-qg0-f70.google.com ([209.85.192.70]) by mxgoog1.mail.janestreet.com with esmtps (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.72) (envelope-from ) id 1aw9qp-00069d-BK for caml-list@inria.fr; Fri, 29 Apr 2016 10:57:03 -0400 Received: by mail-qg0-f70.google.com with SMTP id d90so177352958qgd.3 for ; Fri, 29 Apr 2016 07:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=fw8ZmsxHuFBcCnjwYIsCh/IiIYq058P+H9O+gEwPctU=; b=DClryNZNvXs3R8BoFoUQ/0wO+OOihnjz5ypvt1B7b8Ek9asxksXIwPIqpyBr9NUTaA NbBtYUX9QF0Ih9Df6ordhc3pI/17Y/Tz4He5Ca7WSEJbCGL4Dy6Q2YiPsFfq3nMTNHsO ajssdn8HqvCh1EeHvLWp27OmHnEVt2iS4wL2o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=fw8ZmsxHuFBcCnjwYIsCh/IiIYq058P+H9O+gEwPctU=; b=EY1G1K9P3O8NcWhWDWr0S/14ho7VoHzxwrATwhPJR14c0adYEBrmAC7ess86heCGnn XsoE0FVXDT/Yizs3ZLa2kH+ozvjvPust6B6WSL2CBq+Tt+gNHaEgWZm5r2k1rcMarT6d jE0qm3914DpveMJfdGNG2Me4LrDovfvvXwZTC5bj3sIbqelARy/h0sChqj4zVf0bfjLK 8J3rt5A+ZmFElBXFm6K9zC1GVfDjbT35ZQrVpOFPgWDiwBuMI0RjnXdgtX/YBAlFAVjw 0FgaAkFowZc35FR2671c0+Qh/mQL3DiANAkQR1dX6nwqRAcHxygofSU7+fhzAX21qLQs U5zw== X-Gm-Message-State: AOPr4FXhoYBf4MqivXZUqaqxrmipIInOxslrAO/TJmCRsGXLhFFUKi4uyhxlVXqMRvS4J6APm2kPWCzztimDH7B59xJBI+Ig9/pVJITPb1V8Zco0K2xrbGFNOpvpDSVls+WWamfTrHuYcHidDSE8O6T2NuJWtbHrdrzp56+444Q= X-Received: by 10.176.69.134 with SMTP id u6mr11743272uau.145.1461941823010; Fri, 29 Apr 2016 07:57:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.176.69.134 with SMTP id u6mr11743254uau.145.1461941822835; Fri, 29 Apr 2016 07:57:02 -0700 (PDT) Received: by 10.103.84.67 with HTTP; Fri, 29 Apr 2016 07:57:02 -0700 (PDT) In-Reply-To: <5630123afc948279fc61d5e4c35d9014@in.tum.de> References: <1461935860.9915.100.camel@e130.lan.sumadev.de> <5630123afc948279fc61d5e4c35d9014@in.tum.de> Date: Fri, 29 Apr 2016 15:57:02 +0100 Message-ID: From:Mark Shinwell To:=?UTF-8?Q?Markus_Wei=C3=9Fmann?= Cc:"caml-list@inria.fr" , Gerd Stolpmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-JS-Processed-by: mailcore X-Validation-by: mshinwell@janestreet.com Subject: Re: [Caml-list] Obj.out_of_heap_tag, out of minor heap or memory corruption? 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=C3=9Fmann wrote: > On 2016-04-29 15:17, Gerd Stolpmann wrote: >> >> Am Freitag, den 29.04.2016, 13:04 +0200 schrieb Markus Wei=C3=9Fmann: >>> >>> Hello, >>> >>> I have a server program that crashes after some time with a very >>> strange error: >>> The (=3D) 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 (=3D). >>> 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) =3D >>> print_int x; (* "0" *) >>> assert (x =3D 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 =3D { a : int; b : int } > > let create (a : int) (b : int) =3D > 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) =3D (* 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 =3D 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=C3=9Fmann, M.Sc. > Technische Universit=C3=A4t M=C3=BCnchen > Institut f=C3=BCr 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