Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Xavier Leroy <xavier.leroy@inria.fr>
To: Art Yerkes <ayerkes@gmvnetwork.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] roots.c -- oldify_local_roots
Date: Wed, 30 Jan 2002 21:24:40 +0100	[thread overview]
Message-ID: <20020130212440.B10496@pauillac.inria.fr> (raw)
In-Reply-To: <200201262343.g0QNhbh32555@mail.genxnet.com>; from ayerkes@gmvnetwork.com on Sat, Jan 26, 2002 at 11:43:37PM -0000

> In oldify_local_roots, on line 137, there is an assumption
> that no frame_descriptor is NULL.

Correct.  The frame descriptor is obtained by looking up the return
address (as found on the stack) in a table of frame descriptors
generated by ocamlopt.  Unless there's a serious bug in ocamlopt, all
return addresses that can arise during the execution of
ocamlopt-generated code are described in the table.

>  For the kernel port, I
> put a NULL check in here because I was panicing in the 
> d->retaddr dereference.  If I understand correctly, it is
> 'alright' for me to put a null check in here, because ordinarily
> the elements of frame_descriptor are filled with values from
> caml_frametable, which seems to be generated at compile time.
> Remember that there is a rather odd compilation line that makes
> this go, which I admit is probably to blame for making the rest
> work the wrong way, but I am interested in understanding the 
> process of oldify_local_roots a bit better, including the role
> of the frame_descriptors, which seem to point (if I am correct)
> to the stack frames used by caml functions.

Right.  The frame descriptor tells the GC where to find the GC roots
in the stack frame of an ocamlopt-generated function, and also how big
this stack frame is, so that oldify_local_roots can walk up to the
next stack frame.

> Do I understand this correctly?  A null frame_descriptor seems to
> me to indicate a frame created by an improperly wrapped call.
> (no CAMLparam(n)).

Not quite: for C functions, the GC doesn't have any information on the
stack frame, so the C function have to register their local roots
explicitly using the CAMLxxxx macros.  For ocamlopt-generated
functions, the situation is reversed: the structure of their stack
frames is known, so they don't register roots dynamically.

> Does this really harm anything though?

A missing or incorrect frame descriptor means that the GC might miss
roots contained in the stack frame, and also get the wrong frame size,
thus messing up the scanning of stack frames further down the stack.
So, yes, a null frame descriptor is really harmful!  

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr


      reply	other threads:[~2002-01-30 20:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-26 23:43 Art Yerkes
2002-01-30 20:24 ` Xavier Leroy [this message]

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=20020130212440.B10496@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=ayerkes@gmvnetwork.com \
    --cc=caml-list@inria.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