On Mon, Aug 23, 2010 at 10:05 PM, Mark Shinwell
<mshinwell@janestreet.com> wrote:
> It can be a time-consuming task, but double-check all the rules on
> http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html 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.

OK, I'll do an audit of those calls.

> 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.

I've already tried gdb, which is how I learned that the segfault
occurs during a call
to one of the query functions in my glue module.

Oh, we just added the Dynlink stuff.  There haven't been any recent
crashes until
just now.  That could be an unhappy coincidence; the real issue might
lurk in unrelated
code, as you point out.

-- Paul