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 52B1D7EE20 for ; Sat, 17 Nov 2012 20:46:56 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of markus.mottl@gmail.com) identity=pra; client-ip=209.85.212.180; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of markus.mottl@gmail.com designates 209.85.212.180 as permitted sender) identity=mailfrom; client-ip=209.85.212.180; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@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-wi0-f180.google.com) identity=helo; client-ip=209.85.212.180; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="postmaster@mail-wi0-f180.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooCAODop1DRVdS0jWdsb2JhbABEAcMlCCMBAQEBCQkLCRIGI4IeAQEFQAEUBx0BAwwGBQsNGQITIQEBEQEFARwGE4d6AQMPoQiMM4J4hCYKGScNWYh1AQUMiz9pAYF2AYMVA4hai02BVYsygzAWKYQvgUY X-IronPort-AV: E=Sophos;i="4.83,270,1352070000"; d="scan'208";a="181979902" Received: from mail-wi0-f180.google.com ([209.85.212.180]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 17 Nov 2012 20:46:55 +0100 Received: by mail-wi0-f180.google.com with SMTP id hn14so267356wib.9 for ; Sat, 17 Nov 2012 11:46:55 -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:content-transfer-encoding; bh=Ct36HBLMFHPyZH0Zrw7nCM3PI0utV185UoTs1oUbSpM=; b=Ah/xxq+KOBbaeoUoNpLOmzAeW8eqt7EKi/dRyzVpGjd0Dm/1/VGaO7WWUYYns9pm35 FMwbW6qachP9UyiFuSgcfxwjaM47Tgm4h5v8yWKvroy8PksoD+SCLwpB42U6JPqhxrCT jAT0I1yRvwMm4CnN7tSaYX7GOOjGaSYTf6IWyj1PypUUZ6Uv1IORHODQ5vWreRvjsV8J 98k26K15LPqkuZCWFUuvN4vfSiBthyYjnL+zJAO2oKIFgid0GYJpYk0Hh143TuPbVZo8 SoPLn98qpJovMnaysphSNxee/GNigmj85bHM6QwnrCZPBjtVpOHUTsSzMAsn/yjqHqu/ +Q1A== MIME-Version: 1.0 Received: by 10.180.84.227 with SMTP id c3mr3028604wiz.18.1353181615807; Sat, 17 Nov 2012 11:46:55 -0800 (PST) Received: by 10.180.165.143 with HTTP; Sat, 17 Nov 2012 11:46:55 -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 14:46:55 -0500 Message-ID: From: Markus Mottl To: Samuel Hornus Cc: O Caml Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Segfault in C++ stub with many 'new' allocations On Sat, Nov 17, 2012 at 1:29 PM, Samuel Hornus wro= te: > 1/ I'm writing a stub to the C++ ANN library [1] to find geometric neighb= oring points in space. > The constructor of the main class in this library uses a lot of allocatio= n 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 suff= iciently from the C-style malloc, that bad interactions with OCaml heap hap= pen ? 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 acces= s, and keep pointers inside regular OCaml [float array] or [float array arr= ay]. It was working well (again, for small input point set), but is that sa= fe ? Or can the garbage collector eventually relocate the content of a [fl= oat 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 --=20 Markus Mottl http://www.ocaml.info markus.mottl@gmail.com