Re: [Caml-list] Segfault in C++ stub with many 'new' allocations

[Markus Mottl <markus.mottl@gmail.com>]

On Sat, Nov 17, 2012 at 1:29 PM, Samuel Hornus <Samuel.Hornus@inria.fr> wrote:
> 1/ I'm writing a stub to the C++ ANN library [1] to find geometric neighboring points in space.
> The constructor of the main class in this library uses a lot of allocation with the "new" C++ keyword.
> For small input point sets (e.g. 2500 points), it all seems to work fine.
> For larger ones (50 K points), the C++ constructor crashes.
> My question is : is it possible that the C++ "new" allocator differs sufficiently from the C-style malloc, that bad interactions with OCaml heap happen ?

Having written quite some C++ bindings, I'm unaware of any such
problems.  Segfaults are typically due to incorrect interaction with
the OCaml runtime.

> (I'm passing the input points coordinates in a plain bigarray.)
>
> 2/ Regarding bigarray: before using them, I let the C++ constructor access, and keep pointers inside regular OCaml [float array] or [float array array]. It was working well (again, for small input point set), but is that safe ? Or can the garbage collector eventually relocate the content of a  [float array]  or of a [float array array] ? so that the pointer kept in the C++ class would become dangling ?

No, it's not safe to keep pointers into any standard OCaml array if
allocations can happen.  Kakadu mentions register_global_root in a
reply, but it is not correct that this prevents the GC from moving
values, it merely protects against their reclamation (i.e. it keeps
the values live).

Even if you want to use bigarrays, you will have to protect them from
being reclaimed while your C++ code is accessing them.  But otherwise
their contents will remain fixed in memory, because unlike with
standard arrays it lives outside the OCaml heap.

For numerical calculations I'd strongly suggest using bigarrays,
especially if the C/C++ functions can take a long time to run.  In
this case you could then release the OCaml runtime lock and benefit
from parallelism and/or improved latencies if your OCaml program needs
to react to the outside world.

Regards,
Markus

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com