From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id B3FC07EE20 for ; Sat, 17 Nov 2012 19:35:32 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of kakadu.hafanana@gmail.com) identity=pra; client-ip=209.85.223.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="kakadu.hafanana@gmail.com"; x-sender="kakadu.hafanana@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of kakadu.hafanana@gmail.com designates 209.85.223.182 as permitted sender) identity=mailfrom; client-ip=209.85.223.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="kakadu.hafanana@gmail.com"; x-sender="kakadu.hafanana@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ie0-f182.google.com) identity=helo; client-ip=209.85.223.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="kakadu.hafanana@gmail.com"; x-sender="postmaster@mail-ie0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoCAEvYp1DRVd+2mGdsb2JhbABFFrAEiTeJVQgjAQEBAQEICQ0HFCeCHgEBBAFAARsSCwEDDAYFBAcaISIBEQEFAQoSBhMSh2gBAwkGC6B4jDOCeIQqChknAwpZiHUBBQyMKIUNA4hUhTqHboEcjUYWKYQW X-IronPort-AV: E=Sophos;i="4.83,270,1352070000"; d="scan'208";a="181975216" Received: from mail-ie0-f182.google.com ([209.85.223.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 17 Nov 2012 19:35:31 +0100 Received: by mail-ie0-f182.google.com with SMTP id k10so9053128iea.27 for ; Sat, 17 Nov 2012 10:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CzC7LhgrDdiC+bD4iKgAsqDonxQJc1a5GS3hrEmDe3s=; b=Oq2+asADHX7VHS5lu3Wr2mhcOQzTYX5pe43k1kG2S68sdmBkAdUT+VtIWy6fhFu37w g4/GI7xGgMu/ZFsll2dk+V5dZYVCJkP3CcbGxbwXMlfzNIk1SmjXQGegIMX1fIQzaa6T sK3G9c0c8v4lidKDZsWwRN0wbYO2ZIkhPCl6BuI209JtwC4Ki3tcgH7efNqoT9qkwW7S r67zGmwYJcgTLcaYSkcwHAXGvkih2fk9iqWgek5IauylKfkNKenTAHpZtPW1eSi4fO8C 0M6Dyb7W1kVxvuEE5aLZUwrks1rtbC01NyIxsqL2eSRIGbHzWc9mY8Bp4lgG0YefHpBa UwOQ== MIME-Version: 1.0 Received: by 10.50.152.135 with SMTP id uy7mr2483499igb.17.1353177330908; Sat, 17 Nov 2012 10:35:30 -0800 (PST) Received: by 10.64.51.9 with HTTP; Sat, 17 Nov 2012 10:35:30 -0800 (PST) In-Reply-To: <70435661-3754-4815-9EEF-B52F33D29B5F@inria.fr> References: <70435661-3754-4815-9EEF-B52F33D29B5F@inria.fr> Date: Sat, 17 Nov 2012 22:35:30 +0400 Message-ID: From: Kakadu To: Samuel Hornus Cc: O Caml Content-Type: multipart/alternative; boundary=e89a8f3b9ff9207d1b04ceb526ed Subject: Re: [Caml-list] Segfault in C++ stub with many 'new' allocations --e89a8f3b9ff9207d1b04ceb526ed Content-Type: text/plain; charset=ISO-8859-1 2) AFAIR there are functions like register_global_root which prevents GC from moving values. Best wishes, Kakadu On Sat, Nov 17, 2012 at 10:29 PM, Samuel Hornus wrote: > > Dear all, > > I have two questions. > > 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 ? > > (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 ? > > Thank you in advance, > Sam > > [1] Approximate Nearest Neighbors http://www.cs.umd.edu/~mount/ANN/ > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs --e89a8f3b9ff9207d1b04ceb526ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2) AFAIR there are functions like register_global_root which prevents GC fr= om moving values.

Best wishes,
Kakadu


On Sat, Nov 17, 2012 at 10:29 PM, Sa= muel Hornus <Samuel.Hornus@inria.fr> wrote:

Dear all,

I have two questions.

1/ I'm writing a stub to the C++ ANN library [1] to find geometric neig= hboring 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 diff= ers sufficiently from the C-style malloc, that bad interactions with OCaml = heap happen ?

(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 =A0[fl= oat array] =A0or of a [float array array] ? so that the pointer kept in the= C++ class would become dangling ?

Thank you in advance,
Sam

[1] Approximate Nearest Neighbors http://www.cs.umd.edu/~mount/ANN/
--
Caml-list mailing list. =A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
<= br>
--e89a8f3b9ff9207d1b04ceb526ed--