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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id A675C7ED5C for ; Thu, 2 Aug 2012 00:11:17 +0200 (CEST) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.126.171; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.126.171; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of postmaster@moutng.kundenserver.de designates 212.227.126.171 as permitted sender) identity=helo; client-ip=212.227.126.171; receiver=mail1-smtp-roc.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: AiECADupGVDU436rjWdsb2JhbAArGqd1kRwiAQEBAQkJCwkSBSSCIAEBBScTNAsQGQMEAQEOITwJCggGEwkJCYdjAxAHKbM4A4lYFIs1hwkDjUKJGYgXgVoIh2GBVAc X-IronPort-AV: E=Sophos;i="4.77,696,1336341600"; d="scan'208";a="168835182" Received: from moutng.kundenserver.de ([212.227.126.171]) by mail1-smtp-roc.national.inria.fr with ESMTP; 02 Aug 2012 00:11:16 +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=mreu0) with ESMTP (Nemesis) id 0MSmoL-1TNxKh441t-00Rtjf; Thu, 02 Aug 2012 00:11:15 +0200 Received: from samsung (ip-92-50-84-130.unitymediagroup.de [92.50.84.130]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 8E526C00D0; Thu, 2 Aug 2012 00:11:14 +0200 (CEST) Date: Thu, 02 Aug 2012 00:11:14 +0200 From: Gerd Stolpmann To: Lin Hong Cc: Mailing OCaML References: <1343856245.3275.4@samsung> In-Reply-To: (from lhong@amnh.org on Wed Aug 1 23:44:45 2012) X-Mailer: Balsa 2.4.11 Message-Id: <1343859074.3275.6@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:MB/9bL64J28p3pjiFve4lUFT+RGsL8uygnK7mtb9psz TRux8FxUvcGGmaHG6Ya/pjPxqjGw8AynoWRrUgZsyZAkiMNKZm 43Pj0rMhBuYfAfvB5qj2zGGayePgoMdGRM8R4dO2JHpM55WEog IQoKNQ72i0fLgkGtM7SjfqkBa3qApP+De5AhGaQYoDHi7j+jZe hWBw0FAPOT+AqQd05iuvAIQiHcRAv/B/dQwstZuEjFSeeU7clR jcDROL2DoZ314bx9fF65kIVwCTuW5hIwoK/y6AIT4HU4f8L+E7 PdAQZfSmdkTUbGkdvheQISKdFPhOVvNOekyT0kClxMGo8H131W QEDuNGk3KSfZLZjGImQE= Subject: AW: [Caml-list] Segmentation fault right after caml_alloc_custom Hmmm, this looks all correct. You mention that there are pointers=20=20 inside eltarr. Note that memory allocated with caml_alloc_custom can be=20= =20 moved around by the GC. So if you have pointers in the custom block=20=20 pointing to another part of the block, these will become meaningless=20=20 after such a move. The more standard solution is to put eltarr_p into the custom block,=20=20 not eltarr as a whole. Gerd Am 01.08.2012 23:44:45 schrieb(en) Lin Hong: >=20 > Cheers, > Lin Hong > American Museum of Natural History > POY website : > https://code.google.com/p/poy/ > http://research.amnh.org/scicomp/scripts/download.php >=20 > ________________________________________ > From: caml-list-request@inria.fr [caml-list-request@inria.fr] on=20=20 > behalf of Gerd Stolpmann [info@gerd-stolpmann.de] > Sent: Wednesday, August 01, 2012 5:24 PM > To: Mailing OCaML > Subject: AW: [Caml-list] Segmentation fault right after=20=20 > caml_alloc_custom >=20 > Am 01.08.2012 23:08:12 schrieb(en) Lin Hong: > > Hi Gerd, > > > > thank you for the reply. > > > > how do we know if some value is registered as local root or not? >=20 > Easy: It is your task as developer of a C external to register values, > so if you don't do it, it is not done. >=20 > > the code is long so I will just paste some of it first > > > > in that c file, the value we tried to access but failed was also > > allocated by caml_alloc_custom(ops, size, used, max). > > > > caml_alloc_custom (&sankoff_custom_operations_eltarr,sizeof (struct > > elt_arr)+sz, 1,alloc_custom_max); > > > > the ops was custom_operations with all standard options as follow: > > > > static struct custom_operations sankoff_custom_operations_eltarr =3D { > > "http://www.amnh.org/poy/", > > custom_finalize_default, > > custom_compare_default, > > custom_hash_default, > > custom_serialize_default, > > custom_deserialize_default > > }; > > > > > > the size in caml_alloc_custom is set to the full size , that is the > > data structure itself, plus everything its pointers point to. >=20 > This is probably all ok. Did you use the CAMLparam and CAMLlocal=20=20 > macros? >=20 >=20 > yes, we do, just like following one >=20 > value > sankoff_CAML_median_3(value a, value n, value l, value r) { > CAMLparam4(a,n,l,r); > CAMLlocal1(res); >=20 > //load a,n,l,r to eapA,eapN,eapL and eapR > eltarr_p eapA; > eltarr_p eapN; > eltarr_p eapL; > eltarr_p eapR; > Sankoff_eltarr_custom_val(eapA,a); >=20=20=20=20=20 > sankoff_init_eltarr(eapA,eapA->num_states,eapA->num_elts,-1,-1,-1,-1,NULL= ,0); > Sankoff_eltarr_custom_val(eapN,n); >=20=20=20=20=20 > sankoff_init_eltarr(eapN,eapN->num_states,eapN->num_elts,-1,-1,-1,-1,NULL= ,0); > Sankoff_eltarr_custom_val(eapL,l); >=20=20=20=20=20 > sankoff_init_eltarr(eapL,eapL->num_states,eapL->num_elts,-1,-1,-1,-1,NULL= ,0); > Sankoff_eltarr_custom_val(eapR,r); >=20=20=20=20=20 > sankoff_init_eltarr(eapR,eapR->num_states,eapR->num_elts,-1,-1,-1,-1,NULL= ,0); >=20 >=20 > //we can print everything in eapA~eapR here, they look fine >=20 > //create a new one for return > res =3D caml_alloc_custom (&sankoff_custom_operations_eltarr,sizeof=20= =20 > (struct elt_arr)+sz, 1,alloc_custom_max); >=20 > //if we print eapA~eapR at this point again, they are totally crap. >=20 > neweltarr =3D Sankoff_eltarr_pointer(res); > sankoff_median_3(eapA,eapN,eapL,eapR,neweltarr); >=20 > CAMLreturn(res); > } >=20 > some explanations on functions: >=20 > [Sankoff_eltarr_custom_val] is defined in head file like this: >=20 > #define Sankoff_eltarr_pointer(a) ((struct elt_arr *)=20=20 > Data_custom_val(a)) > #define Sankoff_eltarr_custom_val(to_asgn,a) to_asgn =3D=20=20 > Sankoff_eltarr_pointer(a) >=20 > [sankoff_init_eltarr] set pointers to their right position, since we=20= =20 > are loading the full chunk of memory. not sure it's necessary, but=20=20 > there is no harm to make sure those pointers are correct. >=20 >=20 >=20 > Gerd >=20 >=20 > > > > we also debug with valgrind, the feed back suggest the memory we > > tried to access is indeed freed by caml gc > > > > =3D=3D64563=3D=3D Invalid read of size 4 > > =3D=3D64563=3D=3D at 0x38477B: sankoff_median_3 (in ../poy.native) > > =3D=3D64563=3D=3D by 0x386125: sankoff_CAML_median_3 (in ../poy.nati= ve) > > =3D=3D64563=3D=3D by 0x13177D: camlSankCS__median_3_196 (in=20=20 > ../poy.native) > > =3D=3D64563=3D=3D Address 0x8bb0c04 is 81,108 bytes inside a block of = size > > 512,016 free'd > > =3D=3D64563=3D=3D at 0xAFD7BF: free (vg_replace_malloc.c:325) > > =3D=3D64563=3D=3D by 0x3E5AC2: caml_free_for_heap (in ../poy.native) > > =3D=3D64563=3D=3D by 0x3E5C31: caml_shrink_heap (in ../poy.native) > > =3D=3D64563=3D=3D by 0x3F16FC: caml_compact_heap (in ../poy.native) > > =3D=3D64563=3D=3D by 0x3F1A89: caml_compact_heap_maybe (in ../poy.na= tive) > > =3D=3D64563=3D=3D by 0x3E4EBC: caml_major_collection_slice (in > > ../poy.native) > > =3D=3D64563=3D=3D by 0x3E5692: caml_minor_collection (in ../poy.nati= ve) > > =3D=3D64563=3D=3D by 0x3E57E0: caml_check_urgent_gc (in ../poy.nativ= e) > > =3D=3D64563=3D=3D by 0x3F209C: caml_alloc_custom (in ../poy.native) > > > > > > > > Cheers, > > Lin Hong > > American Museum of Natural History > > POY website : > > https://code.google.com/p/poy/ > > http://research.amnh.org/scicomp/scripts/download.php > > > > ________________________________________ > > From: Gerd Stolpmann [gerd@edgespring.com] > > Sent: Wednesday, August 01, 2012 4:13 PM > > To: Lin Hong > > Cc: Mailing OCaML > > Subject: Re: [Caml-list] Segmentation fault right after > > caml_alloc_custom > > > > You did not send code, so we can only speculate. A reason for this > > behavior could be that a value is not registered as local root, so=20= =20 > the > > GC thinks it is unused. > > > > That you see the problem only on some platforms can be explained by > > the > > different implementations of malloc, and how quickly freed memory is > > really deallocated (i.e. given back to the kernel). I wouldn't give > > much on this observation. > > > > Gerd > > > > Am 01.08.2012 22:05:19 schrieb(en) Lin Hong: > > > Hi all, > > > > > > we have a weird problem here. In a c file, right after one call of > > > 'caml_alloc_custom', some old information we have in memory is=20=20 > gone, > > > then we have the segmentation fault because the code try to access > > > those informations later. > > > > > > turn on debug message with OCAMLRUNPARAM, get this right before=20= =20 > it > > > crash. > > > > > > ...... > > > $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. > > > > > > is it possible that the ocaml garbage collection free memory that=20= =20 > is > > > still in use? > > > > > > the data cause this is kind of big, it doesn't happen right=20=20 > away,and > > > it doesn't happen on every machine (linux with ocaml4 is fine, > > > ocaml3.xx is not. mac with ocaml4 still shows the problem though). > > > > > > any suggestion is appreciated. > > > > > > > > > Thanks, > > > Lin > > > > > > > > > =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 > > > > > > -- > > > 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 > > > > > > > > > > > > -- > > 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 > -- > ------------------------------------------------------------ > 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 > ------------------------------------------------------------ > -- > 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 > -- > 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 --=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 ------------------------------------------------------------=