[Caml-list] roots.c -- oldify_local_roots

[Caml-list] roots.c -- oldify_local_roots

[Art Yerkes]

In oldify_local_roots, on line 137, there is an assumption
that no frame_descriptor is NULL.  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.

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)).  Does this really harm anything though?
-- 
#define ENOTSUP      48      /* Operation not supported                */
#define ENOTKANSTOTO 49      /* Not in kansas anymore, Toto            */
#define EBADE        50      /* Invalid exchange                       */



-------------------
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

Re: [Caml-list] roots.c -- oldify_local_roots

[Xavier Leroy]

> 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