From: Goswin von Brederlow <goswin-v-b@web.de>
To: "François Bobot" <francois.bobot@cea.fr>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] memory corruption with Weak.t in Gc.finalise
Date: Mon, 14 Mar 2016 11:32:42 +0100 [thread overview]
Message-ID: <20160314103240.GA21595@frosties> (raw)
In-Reply-To: <56E2DEB5.8020304@cea.fr>
BOn Fri, Mar 11, 2016 at 04:05:25PM +0100, François Bobot wrote:
> On 08/03/2016 20:04, Goswin von Brederlow wrote:
> >On Tue, Mar 08, 2016 at 11:00:33AM -0500, Gabriel Scherer wrote:
> >>It's great that you have a minimal reproduction example. Could you
> >>create an issue on the issue tracker?
> >> http://caml.inria.fr/mantis/
> >>
> >>Issues on the bugtracker are easier to keep track of than mails on the
> >>caml-list.
> >
> >If it is a bug in the compiler and not just my code then sure.
> >
>
> Perhaps a bug in your code, I haven't ran your code; just read it.
>
> >>>
> >>>class obj = object(self)
> >>> val weak = Weak.create 1
> >>> initializer Weak.set weak 0 (Some self)
> >>> initializer setup weak
> >>> initializer Gc.finalise cleanup self
> >>>end
> >>>
> >>>let () =
> >>> Printf.printf "Creating object\n%!";
> >>> ignore (new obj);
> >>> test ()
> >>>
>
> >>>void test(void) {
> >>> CAMLparam0();
> >>> CAMLlocal1(obj);
> >>> printf("%s\n", __PRETTY_FUNCTION__);
> >>> printf(" weak = 0x%lx\n", weak);
> >>> if (weak != 0) {
> >>> obj = Field(weak, 1);
> >>> printf(" obj = 0x%lx\n", obj);
> >>> if (obj != 0) {
> >>> printf(" tag = %d\n", Tag_val(obj));
> >>> }
>
> If the weak pointer is unset, obj is not equal to 0 but to caml_weak_none
> (in 4.03/trunk caml_ephe_none). And I think you are in this case since `(new
> obj)` can be immediately garbage collected. caml_ephe_none should not be
> dereferenced:
> ```
> static value ephe_dummy = 0;
> value caml_ephe_none = (value) &ephe_dummy;
> ```
>
> Thank you for your mantis ticket
> http://caml.inria.fr/mantis/view.php?id=7173 that asks for a C API for weak
> pointers/ephemerons.
>
> Best,
Still using 4.02. This is a new thing.
Still Weak.t needs to interact cleanly with the Gc. Guessing at the
internal state of Weak.t is bad. Let's fix this for 4.03.
MfG
Goswin
next prev parent reply other threads:[~2016-03-14 10:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-08 15:49 Goswin von Brederlow
2016-03-08 16:00 ` Gabriel Scherer
2016-03-08 19:04 ` Goswin von Brederlow
2016-03-11 15:05 ` François Bobot
2016-03-14 10:32 ` Goswin von Brederlow [this message]
2016-03-14 16:44 ` François Bobot
2016-03-15 9:43 ` Goswin von Brederlow
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=20160314103240.GA21595@frosties \
--to=goswin-v-b@web.de \
--cc=caml-list@inria.fr \
--cc=francois.bobot@cea.fr \
/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