Version française
Home     About     Download     Resources     Contact us    
Browse thread
Calling C from OCaml, GC problems
[ 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: Calling C from OCaml, GC problems
>  1. the ocaml doc (paragraph 15.5) states that CAMLparam and CAMLreturn
>     macros should be used. However, example code in 15.7 does not use
>     them (even if functions have value typed parameters). The Unix
>     interfacing code ocaml-2.04/otherlibs/unix/) doesn't use those macro
>     either. Faulty doc?  Are those macros not mandatory? What is the
>     rationale?

We've been through several designs for the "local root registration" API.
The CAMLxxx macros are the latest design, and the one that we think is
the easiest to use.  Most parts of the systems were written before
those macros were introduced, and thus still use an older API in 2.04
(but the next release of OCaml will use the new API).

>  2. when compiling, I've tons of warning like this:
> bdd_interface.c: In function `mlbdd_alloc_manager':
> bdd_interface.c:136: warning: left-hand operand of comma expression has no effect
> bdd_interface.c:136: warning: unused variable `caml__dummy_result'

I think those warnings are harmless, and are due to the way the
CAMLxxx macros are written in 2.04.  But only Damien Doligez knows for
sure...

>  3. The code is running on small examples but segfault on bigger
>     ones. From gdb backtrace, it seems clear that my bug is releated to
>     a GC problem:

That is often due to a local root not being registered, or being
incorrectly registered.

>     The bdd library is using itself a memory management library calling
>     sbrk(2). Can it trigger problems with OCaml GC (like the GC going
>     into bdd structures)?

This shouldn't be a problem.  OCaml allocates its heap using malloc(),
and scans only the portions of the memory space that it allocated itself.
There might be funky interactions between sbrk() and malloc(), but
this is unlikely, as it would cause problem with the BDD library even
in C programs.

- Xavier Leroy