From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA10415; Wed, 30 Jan 2002 21:25:39 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA10767 for ; Wed, 30 Jan 2002 21:25:38 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g0UKOfr09213; Wed, 30 Jan 2002 21:24:41 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA10744; Wed, 30 Jan 2002 21:24:40 +0100 (MET) Date: Wed, 30 Jan 2002 21:24:40 +0100 From: Xavier Leroy To: Art Yerkes Cc: caml-list@inria.fr Subject: Re: [Caml-list] roots.c -- oldify_local_roots Message-ID: <20020130212440.B10496@pauillac.inria.fr> References: <200201262343.g0QNhbh32555@mail.genxnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200201262343.g0QNhbh32555@mail.genxnet.com>; from ayerkes@gmvnetwork.com on Sat, Jan 26, 2002 at 11:43:37PM -0000 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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