Previous week Up Next week


Here is the latest Caml Weekly News, for the week of March 30 to April 06, 2010.

  1. Random segfaults / out of memory
  2. orpc 0.3
  3. GraphPDF - PDF version of Graphics module
  4. Chess III Arena v0.8
  5. The course on Unix System programming in OCaml is translated
  6. Other Caml News

Random segfaults / out of memory


Deep in this thread, Goswin von Brederlow said:
I finaly tracked down the issue with the help of Erkki Seppala.

First problem:

I had the function declared as "noalloc" but used CAMLparam2() in
it. That seems to cause random segfaults. I don't understand why but if
I remove the "noalloc" then it works.

Second problem:

When I remove the CAMLparam2() the finalizer is called too early:

CAMLprim value md5_update_bigarray(value context, value vb)
 //CAMLparam2(context, vb);
 struct helper *helper = (struct helper*)Data_custom_val(context);
 struct MD5Context *ctx = helper->ctx;
 fprintf(stderr, "update_bigarray: helper = %p, ctx = %p\n", helper, ctx);
 struct caml_ba_array * b = Caml_ba_array_val(vb);
 unsigned char *data = b->data;
 uintnat len = caml_ba_byte_size(b);
 caml_MD5Update(ctx, data, len);
 return Val_unit;

 let rec loop () =
   Mutex.lock mutex;
   if !num = 0
   then Mutex.unlock mutex
   else begin
     decr num;
     Mutex.unlock mutex;
     let context = context () in
     let () = update_bigarray context buf
       loop ()
   loop ()

This sometimes results in the following code flow:

 context ()                             <- allocates memory
 update_bigarray context buf
 GC runs
 context is finalized                   <- frees memory
  caml_MD5Update(ctx, data, len);      <- writes to ctx which is freeed

Looks like ocamlopt really is so smart that is sees that context is
never used after the call to update_bigarray and removes it from the
root set before calling update_bigarray. It assumes the update_bigarray
will hold all its arguments alive itself, which is a valid assumption.

This is a tricky situation. The md5_update_bigarray() on its own is a
"noalloc" function. But due to the caml_enter_blocking_section() another
thread can alloc and trigger a GC run in parallel. So I guess that makes
the function actually not "noalloc".
David Baelde then asked:
Thanks for reporting about your experience! This made me suspect
noalloc in a bug of mine, and indeed removing a bunch of noalloc did
the trick. Now I'd like to understand.

Unlike in your example, global roots were registered for the bigarrays
in "my" functions. This should avoid that they are freed when the
global lock is released. Still, noalloc seems wrong with those

I'm not sure yet which function is problematic in my case, but they
all follow the same scheme, see for example

So, is it really forbidden to release the global lock in a noalloc function?
To which Xavier Leroy replied:
> So, is it really forbidden to release the global lock in a noalloc function?

Yes.  Actually, it is forbidden to call any function of the OCaml
runtime system from a noalloc function.

Explanation: ocamlopt-generated code caches in registers some global
variables of importance to the OCaml runtime system, such as the
current allocation pointer.

When calling a regular (no-"noalloc") C function from OCaml, these
global variables are updated with the cached values so that everything
goes well if the C function allocates, triggers a GC, or releases the
global lock (enabling a context switch).

This updating is skipped when the C function has been declared
"noalloc" -- this is why calls to "noalloc" functions are slightly
faster.  The downside is that the runtime system is not in a
functioning state while within a "noalloc" C function, and must
therefore not be invoked.

The cost of updating global variables is small, so "noalloc" makes
sense only for short-running C functions (say, < 100 instructions) like
those from the math library (sin, cos, etc).  If the C function makes
significant work (1000 instructions or more), just play it safe and
don't declare it "noalloc".
Markus Mottl then said:
It may not always be clear to developers whether a function provided
by the OCaml API is safe.  E.g. calling Val_int is fine (at least now
and for the foreseeable future), but caml_copy_string is not.  I agree
that people should generally avoid noalloc.  The speed difference is
clearly negligible in almost all practical cases.

Note, too, that sometimes people forget that they had declared a
previously safe function as "noalloc", but later change the C-code in
ways that breaks this property.  The tiny extra performance may not be
worth that risk.

orpc 0.3


Jake Donham announced:
I am happy to announce version 0.3 of orpc, a tool for generating RPC
bindings from OCaml signatures. Orpc can generate ONC RPC stubs for
use with Ocamlnet (in place of ocamlrpcgen), and it can also generate
RPC over HTTP stubs for use with ocamljs. You can use most OCaml types
in interfaces, as well as exceptions and labelled/optional arguments.

Changes since version 0.2 include

 * a way to use types defined outside the interface file, so you can
use a type in more than one interface
 * support for polymorphic variants
 * a way to specify "abstract" interfaces that can be instantiated for
synchronous, asynchronous, and Lwt clients and servers
 * bug fixes

Development of orpc has moved from Google Code to Github; see

 * project page:
 * documentation:
 * downloads:

I hope you find this work useful. Let me know what you think.

GraphPDF - PDF version of Graphics module


John Whitington announced:
I’ve written a version of Ocaml’s Graphics module which outputs PDF directly,
using the CamlPDF library - its only dependency. It’s based on the approach of
Pierre Weis’ GraphPS program.

It has the same API as Ocaml’s module - just have your build process find the
GraphPDF files before it finds the system ones - the vast majority of programs
shouldn’t need altering.

Chess III Arena v0.8


Grant Olson announced:
Chess III Arena is a chess game that uses Quake 3 characters as the
chess pieces.  Version 0.8 includes many improvements over the last
version.  I'll only go into two major improvements here:

1) The distribution now includes everything you need to play.  Previous
versions required access to an official copy of Quake 3 to get the
character art.  This version now includes gpl licensed character art
courtesy of the openArena project.

2) C3A can now be used as a graphical front-end for gnuchess, allowing
you to play a computer opponent.

More information, source downloads, and a binary Windows download can be
found here:

The course on Unix System programming in OCaml is translated


Daniel Bünzli announced:
It is my pleasure to announce that Xavier Leroy and Didier Rémy's
course on Unix system programming in Objective Caml is now available
in english at this address :

If you had a look at the individual publications of the chapters
announced on the project feed you may want to have a look again: some
parts of the text were improved and a few translation errors were
corrected in the final version.

The translation was made by :

* Eric Cooper
* Eliot Handelman
* Priya Hattiangdi
* Thad Meyer
* Prashanth Mundkur
* Richard Paradies
* Till Varoquaux
* Mark Wong-VanHaren
* Daniel C. Bünzli

And the resulting text was proofread by :

* David Allsopp
* Erik de Castro Lopo
* John Clements
* Anil Madhavapeddy
* Prashanth Mundkur.

A big thank to all of them for the time they provided for the project.

A special mention goes to Prashanth Mundkur who was very supportive
and responsive all along. He not only proofread more than one chapter
but also provided fixes and improvements for every part of the

Thanks also to all the people working on for the hosting

Other Caml News

From the ocamlcore planet blog:
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to the
recent posts from the ocamlcore planet blog at

The course on Unix System programming in OCaml is translated:

Xavierbot 0.9:

ocaml bindings for picosat:

What is the defacto OCaml build tool?:

What is the defacto OCaml unit testing tool?:

GraphPDF: A PDF Version of Ocaml’s Graphics Module:

orpc 0.3:

Tip: find out when filesystems get full with virt-df (working version!):

Pourquoi je quitte l'expérience démocratique:

Old cwn

If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.

If you also wish to receive it every week by mail, you may subscribe online.

Alan Schmitt