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 4CB4C7ED5C for ; Wed, 1 Aug 2012 23:08:17 +0200 (CEST) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of lhong@amnh.org) identity=pra; client-ip=216.73.244.163; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="lhong@amnh.org"; x-sender="lhong@amnh.org"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of lhong@amnh.org) identity=mailfrom; client-ip=216.73.244.163; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="lhong@amnh.org"; x-sender="lhong@amnh.org"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@spam.amnh.org) identity=helo; client-ip=216.73.244.163; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="lhong@amnh.org"; x-sender="postmaster@spam.amnh.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkCAJ+ZGVDYSfSjkWdsb2JhbAArGqd1kT4BAQEBFBIUJ4IgAQEBBDo0CxACAQgRBAEBCwMREDITCggCBA4FCAEJh2wDDAEKKbMvA4lYi0mGKWADlluIF4FaCIdfgVYH X-IronPort-AV: E=Sophos;i="4.77,696,1336341600"; d="scan'208";a="168832250" Received: from mail-mx-001.amnh.org (HELO spam.amnh.org) ([216.73.244.163]) by mail1-smtp-roc.national.inria.fr with ESMTP; 01 Aug 2012 23:08:16 +0200 X-ASG-Debug-ID: 1343855294-041b4a169850eae0001-jBxyQn Received: from amnh.org ([172.16.8.238]) by spam.amnh.org with ESMTP id BZJCB8gtX2oGcwMw; Wed, 01 Aug 2012 17:08:14 -0400 (EDT) X-Barracuda-Envelope-From: lhong@amnh.org Received: from MAIL-MBX-004.internal.amnh.org ([fe80::7070:e0a1:bc56:c30a]) by MAIL-CASHT-003.internal.amnh.org ([fe80::a487:6081:d54f:db9e%12]) with mapi id 14.01.0289.001; Wed, 1 Aug 2012 17:08:13 -0400 From: Lin Hong X-Barracuda-Apparent-Source-IP: fe80::7070:e0a1:bc56:c30a To: Gerd Stolpmann CC: Mailing OCaML Thread-Topic: [Caml-list] Segmentation fault right after caml_alloc_custom X-ASG-Orig-Subj: RE: [Caml-list] Segmentation fault right after caml_alloc_custom Thread-Index: AQHNcCIrQXA9cZOHwESkX6hsHwCJmJdFbKyB Date: Wed, 1 Aug 2012 21:08:12 +0000 Message-ID: References: (from lhong@amnh.org on Wed Aug 1 22:05:19 2012),<1343852029.3275.1@samsung> In-Reply-To: <1343852029.3275.1@samsung> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.8.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[172.16.8.238] X-Barracuda-Start-Time: 1343855294 X-Barracuda-URL: http://spam.amnh.org:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at amnh.org X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=4.0 KILL_LEVEL=9.0 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.104404 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M Subject: RE: [Caml-list] Segmentation fault right after caml_alloc_custom Hi Gerd, thank you for the reply. how do we know if some value is registered as local root or not? 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).=20=20 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,=20 custom_deserialize_default }; the size in caml_alloc_custom is set to the full size , that is the data st= ructure itself, plus everything its pointers point to. we also debug with valgrind, the feed back suggest the memory we tried to= access is indeed freed by caml gc=20 =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.native) =3D=3D64563=3D=3D by 0x13177D: camlSankCS__median_3_196 (in ../poy.nativ= e) =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.native) =3D=3D64563=3D=3D by 0x3E4EBC: caml_major_collection_slice (in ../poy.na= tive) =3D=3D64563=3D=3D by 0x3E5692: caml_minor_collection (in ../poy.native) =3D=3D64563=3D=3D by 0x3E57E0: caml_check_urgent_gc (in ../poy.native) =3D=3D64563=3D=3D by 0x3F209C: caml_alloc_custom (in ../poy.native) =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 ________________________________________ 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 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 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 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 is > still in use? > > the data cause this is kind of big, it doesn't happen right 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 > >