[ocaml-ctypes] Binding that works in bytecode, segfaults in native code

[Hezekiah M. Carty]

Hello,

I have been working on and off on ctypes-based OCaml bindings for the
GDAL library (http://gdal.org).  The process has been quite pleasant
so far.  The bindings are available here:
https://github.com/hcarty/ocaml-gdal

I've run into what I expect is a memory management issue with my
bindings to GDAL's raster warping API.  This section of GDAL handles
reshaping an image to fit different physical dimensions and/or
coordinate systems.  This involves a lot of calls from OCaml to C to
OCaml to C.  The call to the C library involves building and passing
in a large struct defined here:

http://www.gdal.org/structGDALWarpOptions.html

with the corresponding ctypes binding here:

https://github.com/hcarty/ocaml-gdal/blob/master/src/gdal/warp.ml#L26

examples/warptut.ml in the ocaml-gdal repository is meant to
illustrate how to use the Warp module.  When warptut.ml is compiled to
a bytecode executable on my system I can run it without issue.
However I get a consistent segfault when trying to run the same
program compiled to native code.  Running both under gdb shows that
the correct/expected code path within GDAL is taken in the bytecode
case while an incorrect path involving callbacks to unexpected
functions is taken in the native code case.

warptut.ml is sprinkled with Gc.full_major calls to try to locate the
source of the problem.  The actual segfault happens here:

https://github.com/hcarty/ocaml-gdal/blob/master/examples/warptut.ml#L97

A sample input file to test the warptut.{byte, native} is available here:

http://0ok.org/ocaml/rtma2p5.t06z.2dvaranl_ndfd.grb2

You can test warptut with:

./warptut.native rtma2p5.t06z.2dvaranl_ndfd.grb2 out.tif

Running

ocamlbuild warptut.byte

will give the equivalent bytecode executable which can be run the same way.

If anyone is interested in helping debug this issue I'm happy to
provide more information on how the bindings are structured.  In the
mean time are there any suggestions or techniques you can recommend to
help track down the cause of this segfault?  I've tried to ensure that
I am keeping references to data passed to C on the OCaml end to avoid
data disappearing but I must have missed something.

The system I've been testing this on is running 64bit Ubuntu 12.04,
OCaml 4.01.0 and 4.02.0, and the latest ctypes from opam.

Thank you,

Hez