From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <Samuel.Hornus@inria.fr>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by sympa.inria.fr (Postfix) with ESMTPS id 3956A7EE20
	for <caml-list@sympa.inria.fr>; Sat, 17 Nov 2012 20:18:07 +0100 (CET)
X-IronPort-AV: E=Sophos;i="4.83,270,1352070000"; 
   d="scan'208";a="162850825"
Received: from 4be54-7-78-230-69-17.fbx.proxad.net (HELO [192.168.0.23]) ([78.230.69.17])
  by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 17 Nov 2012 20:18:06 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1283)
From: Samuel Hornus <Samuel.Hornus@inria.fr>
In-Reply-To: <50A7E138.9090601@etorok.net>
Date: Sat, 17 Nov 2012 20:18:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <43A673FD-DC80-4406-8984-A74B181BC825@inria.fr>
References: <70435661-3754-4815-9EEF-B52F33D29B5F@inria.fr> <CAGmVoG2e6jG3s1-f==UsPq9MKxziS+N8PK2DfqwC8c4zawM9pQ@mail.gmail.com> <0BEF3A04-3297-4084-BE4D-13ACCC4D431E@inria.fr> <50A7E138.9090601@etorok.net>
To: O Caml <caml-list@inria.fr>
X-Mailer: Apple Mail (2.1283)
Subject: Re: [Caml-list] Segfault in C++ stub with many 'new' allocations


On 17 nov. 2012, at 20:10, T=F6r=F6k Edwin wrote:

> On 11/17/2012 08:42 PM, Samuel Hornus wrote:
>>=20
>> Regarding my first question, if it can help, here is the relevant part o=
f my C++ code:
>> extern "C" value ann_create_bd_tree_flat_ba (value ba, value n, value di=
m)
>> {
>>    CAMLparam3(ba,n,dim);
>>    ANNbd_tree * ptr =3D create_bd_tree_flat((ANNcoord*)Caml_ba_data_val(=
ba), Int_val(n), Int_val(dim));
>>    CAMLreturn ((value)ptr);
>=20
> I don't think this is safe. Shouldn't the return value be wrapped in a cu=
stom block?
> If the GC tries to interpret this as an OCaml value (which it isn't) it m=
ight crash.

Currently, as advised in F. Monier webpage http://www.linux-nantes.org/~fmo=
nnier/ocaml/ocaml-wrapping-c.php#ref_finalise, I wrap the pointer, in the O=
Caml code, inside an abstract OCaml type with a finalizer. Could there stil=
l be problems with the GC ?
That being said, my crash happens *inside* the C++ constructor, well before=
 the garbage collection may have kicked in. The same code, compiled as a pu=
re C++ program works without problem, even with millions of points.
Is it possible that C++ called from OCaml has a limited memory allocation s=
pace?
--=20
Sam=