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
Segfaults with Dynlink with OCaml 3.11
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-08-23 (12:05)
From: Mark Shinwell <mshinwell@j...>
Subject: Re: [Caml-list] Segfaults with Dynlink with OCaml 3.11
On Mon, Aug 23, 2010 at 09:47:43PM +1000, Paul Steckler wrote:
> On Mon, Aug 23, 2010 at 9:06 PM, Stéphane Glondu <> wrote:
> > Does your real large program use C bindings? Are you able to reproduce
> > the segfaults with pure OCaml code?
> Yes, the large program has C bindings, including calls into dynamically loaded
> .so files (Linux dynamic libraries).  Anything I should look into for those?

It can be a time-consuming task, but double-check all the rules on are being followed.
For example, watch out for things like variables of type [value] that are
wrongly not protected with CAMLlocal/CAMLparam macros across allocation points
when the variable's contents are needed later, uses of the Field macro as an
lvalue in a situation where instead Store_field must be used, assigning to
generational global roots without using the correct function, etc.  Just one
minor transgression could be the cause of a hard-to-find error at some random
point during program execution.

Have you tried using gdb to determine the stack backtrace when it segfaults?
Also, if it can be done without disturbing too much code, it might be worth
trying to eliminate Dynlink from the program as a test.