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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id 5E5147ED5C for ; Wed, 1 Aug 2012 22:16:14 +0200 (CEST) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.126.186; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.126.186; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of postmaster@moutng.kundenserver.de designates 212.227.126.186 as permitted sender) identity=helo; client-ip=212.227.126.186; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@moutng.kundenserver.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEBACeOGVDU4366jWdsb2JhbAArGqd1kRwiAQEBAQkJCwkSBSSCJzo0Lh1dCRIGEwkJh2wDEAcpmxOYEQOJWBSLNYcJA41CiRmIF4Fah2mBVAc X-IronPort-AV: E=Sophos;i="4.77,696,1336341600"; d="scan'208";a="152237847" Received: from moutng.kundenserver.de ([212.227.126.186]) by mail4-smtp-sop.national.inria.fr with ESMTP; 01 Aug 2012 22:16:13 +0200 Received: from office1.lan.sumadev.de (dslb-094-219-223-014.pools.arcor-ip.net [94.219.223.14]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0LiawD-1TUL3p492D-00cvoh; Wed, 01 Aug 2012 22:16:13 +0200 Received: from samsung (ip-92-50-84-130.unitymediagroup.de [92.50.84.130]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 88A28C00D0 for ; Wed, 1 Aug 2012 22:16:12 +0200 (CEST) Date: Wed, 01 Aug 2012 22:16:12 +0200 From: Gerd Stolpmann Reply-To: Gerd Stolpmann To: Mailing OCaML In-Reply-To: X-Mailer: Balsa 2.4.11 Message-Id: <1343852172.3275.2@samsung> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Provags-ID: V02:K0:DR81aE86cZjLK+hBgqa9jZ9ZzDRXA72xb1sMqRsdril baly/VyabVuj9kCPnsFdOBH0RyCPfgjQEUkDa1+F1rKfyDGGzj 6obTt4XouYbvea2HCx0mDqSt8PDOn2C71f19J28sl09JJmQSkA dxwypGhswRHrJNxf3ZUoGqk6sItRd8wy1sYm7z+yRLSl6rFxRQ VajgBL/nkgYqUECh8sCCETTfxphh4RDgI1PjmTr1o+0rmXHt1K qJXrVPKemeYKl61C3x4mZjo8p5o4vfjtYnZ42WSjDcQ6t7LDI3 MnX0ZErkx76Cve5ye+d43wMgjtFg9tNERh0GW6mQFRjNChyh8C IO/YRsEWi5qcMpLwAqAA= Subject: AW: [Caml-list] Segmentation fault right after caml_alloc_custom You did not send code, so we can only speculate. A reason for this=20=20 behavior could be that a value is not registered as local root, so the=20= =20 GC thinks it is unused. That you see the problem only on some platforms can be explained by the=20= =20 different implementations of malloc, and how quickly freed memory is=20=20 really deallocated (i.e. given back to the kernel). I wouldn't give=20=20 much on this observation. Gerd Am 01.08.2012 22:05:19 schrieb(en) Lin Hong: > Hi all, >=20 > we have a weird problem here. In a c file, right after one call of=20=20 > 'caml_alloc_custom', some old information we have in memory is gone,=20= =20 > then we have the segmentation fault because the code try to access=20=20 > those informations later. >=20 > turn on debug message with OCAMLRUNPARAM, get this right before it=20=20 > crash. >=20 > ...... > $Starting new major GC cycle > Marking 9223372036854775807 words > Subphase =3D 10 > Sweeping 9223372036854775807 words > Compacting heap... > Shrinking heap to 37696k bytes > Shrinking heap to 36704k bytes > Shrinking heap to 35712k bytes > Shrinking heap to 34720k bytes > Shrinking heap to 33728k bytes > Shrinking heap to 32736k bytes > Shrinking heap to 31744k bytes > Shrinking heap to 30752k bytes > done. >=20 > is it possible that the ocaml garbage collection free memory that is=20= =20 > still in use? >=20 > the data cause this is kind of big, it doesn't happen right away,and=20= =20 > it doesn't happen on every machine (linux with ocaml4 is fine,=20=20 > ocaml3.xx is not. mac with ocaml4 still shows the problem though). >=20 > any suggestion is appreciated. >=20 >=20 > Thanks, > Lin >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > American Museum of Natural History > POY website : > https://code.google.com/p/poy/ > http://research.amnh.org/scicomp/scripts/download.php >=20 > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >=20 >=20 --=20 ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------=