Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] roots.c -- oldify_local_roots
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <xavier.leroy@i...>
Subject: Re: [Caml-list] roots.c -- oldify_local_roots
> 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:  FAQ:
To unsubscribe, mail  Archives: