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
Re: Still strange GC problems with OCaml and C: OCaml 2.04 bug?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-02-22 (10:55)
From: David.Mentre@i...
Subject: Congratulation! Bug found!! (GC & C interfacing problems)
Hi Markus, Hi all camlists,

You were right Markus. Using directly the Field macro fixed my bug.

Markus Mottl <> writes:

> You use "Store_field" throughout the code to assign pointers to fields in
> structures which were allocated using "alloc_final".
> I once had a similar bug in my PCRE-library, but Gerd Stolpmann was so kind
> to send me the patch and explain the problem. Here his translated
> explanation (seems reasonable):
>   - after "alloc_small" the fields have to be initialized with
>     "Field(var, n) = ...", not with "Store_field". The last version writes
>     (with some bad luck) the address of the field into a list of addresses
>     which have to be moved in case of a minor GC.
>   - The fields of "alloc_final" are not considered by the GC. Therefore,
>     they, too, have to be written to using "Field(var, n)" (or you may
>     cast them to a normal C-struct). "Store_field" has, again, unexpected
>     side effects.

The explanation (or a guess ;) :

  1. a memory block is allocated with alloc_final, therefore this block
     internals should not be considered by the GC.

  2. I use the Store_field macro to update block content. 

  3. However, this macro is calling modify (function defined in
     byterun/memory.c) which in turn calls the Modify macro (defined in
     byterun/memory.h). As Markus said, this macro adds the address
     given in argument to a list of memory addresses (ref_table_ptr)
     that should be examined by the GC at collection time.

  4. So, we have a GC-opaque memory block whose content adresses have
     been added to a GC to-examine-later list. Therefore, at GC time:

> In case this is really the bug (probably), I'd suggest a revision of the
> C-interface-documentation. At least to me it was not obvious that
> "Store_field" leads to such additional, unexpected behaviour.

I also subscribe to this documentation revision. I also volunteer, if
needed, to review/rewrite the doc part related to Interfacing C with

> Good luck squeezing the bug,

I've squeezed it, with your help. :)

One again, many many thanks,
Best regards,
-- --
 Opinions expressed here are only mine.