From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Mailing OCaML <caml-list@inria.fr>
Subject: AW: [Caml-list] Segmentation fault right after caml_alloc_custom
Date: Wed, 01 Aug 2012 23:24:05 +0200 [thread overview]
Message-ID: <1343856245.3275.4@samsung> (raw)
In-Reply-To: <C960B6881E802A459A09A7DAD55690053E7B66D7@MAIL-MBX-004.internal.amnh.org>
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?
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.
> 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 = {
> "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.
This is probably all ok. Did you use the CAMLparam and CAMLlocal macros?
Gerd
>
> we also debug with valgrind, the feed back suggest the memory we
> tried to access is indeed freed by caml gc
>
> ==64563== Invalid read of size 4
> ==64563== at 0x38477B: sankoff_median_3 (in ../poy.native)
> ==64563== by 0x386125: sankoff_CAML_median_3 (in ../poy.native)
> ==64563== by 0x13177D: camlSankCS__median_3_196 (in ../poy.native)
> ==64563== Address 0x8bb0c04 is 81,108 bytes inside a block of size
> 512,016 free'd
> ==64563== at 0xAFD7BF: free (vg_replace_malloc.c:325)
> ==64563== by 0x3E5AC2: caml_free_for_heap (in ../poy.native)
> ==64563== by 0x3E5C31: caml_shrink_heap (in ../poy.native)
> ==64563== by 0x3F16FC: caml_compact_heap (in ../poy.native)
> ==64563== by 0x3F1A89: caml_compact_heap_maybe (in ../poy.native)
> ==64563== by 0x3E4EBC: caml_major_collection_slice (in
> ../poy.native)
> ==64563== by 0x3E5692: caml_minor_collection (in ../poy.native)
> ==64563== by 0x3E57E0: caml_check_urgent_gc (in ../poy.native)
> ==64563== 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 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 = 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
> >
> >
> > =======================
> > 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
>
>
>
--
------------------------------------------------------------
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
------------------------------------------------------------
next prev parent reply other threads:[~2012-08-01 21:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-01 20:05 Lin Hong
2012-08-01 20:16 ` AW: " Gerd Stolpmann
[not found] ` <1343852029.3275.1@samsung>
2012-08-01 21:08 ` Lin Hong
2012-08-01 21:24 ` Gerd Stolpmann [this message]
2012-08-01 21:44 ` Lin Hong
2012-08-01 22:11 ` AW: " Gerd Stolpmann
2012-08-02 1:01 ` Lin Hong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1343856245.3275.4@samsung \
--to=info@gerd-stolpmann.de \
--cc=caml-list@inria.fr \
--cc=gerd@edgespring.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox