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
Heaps size problems with "caml_alloc_small" in foreign function interfaces
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-07-11 (09:40)
From: Richard Jones <rich@a...>
Subject: Re: [Caml-list] Heaps size problems with "caml_alloc_small" in foreign function interfaces
On Fri, Jul 11, 2008 at 06:21:51PM +1000, Sean Seefried wrote:
> I'm having a problem where sometimes a call to "caml_alloc_small" from  
> C results in a segmentation fault. If I increase the size of the stack  
> using OCAMLRUNPARAM=s=1000k then I don't get the crash anymore. It  
> seems strange that I have to increase the size of the heap manually  
> like this. Is this because I'm calling this function from C?

Seems like you have confusion over heap & stack.

First of all, caml_alloc_small is limited to small allocations, so
number of words allocated must be <= Max_young_wosize.  You don't post
any example code so we can't see whether that is true in your code.

Secondly (and much more likely to be the problem), the caml_alloc*
functions allocate uninitialised memory.  If the garbage collector
gets to run before you've properly initialized all the fields then the
GC will hit an uninitialised field and a segfault could be the result.

  eg: This is a fail:

  v = caml_alloc (2, 0);
  vv = caml_alloc (3, 0);  /* GC could run here */
  Store_field (v, 0, vv);

Changing the _stack_ size (or other tunables) probably just changes
something about when the garbage collector runs, and thus moves the
bug around.

> If I want to increase the size of the heap in C how do I do this?  
> Could I write a "safe" caml_alloc_small which first checks to see if  
> there is enough memory and then increases the heap size if not?

The "size of the heap in C" is (for most operating systems) extended
automatically by malloc.  What you're saying here isn't necessary -
you must have some other bug.

I suggest you post some code which exhibits the problem.


Richard Jones
Red Hat