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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id 79EB37EE20 for ; Sat, 17 Nov 2012 20:10:56 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of edwin+ml-ocaml@etorok.net) identity=pra; client-ip=176.9.138.55; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of edwin+ml-ocaml@etorok.net designates 176.9.138.55 as permitted sender) identity=mailfrom; client-ip=176.9.138.55; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of postmaster@mail.etorok.net designates 176.9.138.55 as permitted sender) identity=helo; client-ip=176.9.138.55; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="postmaster@mail.etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANTgp1CwCYo3/2dsb2JhbABFgmzAQoEIgh4BAQUyAQ0BATYCDwsYCRYPCQMCAQIBRRMIAogKA6t6hDcBBY5HBow0gWaDJ5V/kEOCcQ X-IronPort-AV: E=Sophos;i="4.83,270,1352070000"; d="scan'208";a="162850468" Received: from mail.etorok.net ([176.9.138.55]) by mail4-smtp-sop.national.inria.fr with ESMTP; 17 Nov 2012 20:10:53 +0100 Received: from [IPv6:2a02:2f02:1022:9239:1e6f:65ff:fe23:db0d] (unknown [IPv6:2a02:2f02:1022:9239:1e6f:65ff:fe23:db0d]) by mail.etorok.net (Postfix) with ESMTPSA id BF49746AF for ; Sat, 17 Nov 2012 20:10:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=etorok.net; s=MAILOUT; t=1353179452; bh=YsZSIhTzPzqVAhHRLFqV7m7ZHCkmlKM2M94maCZueJk=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=hkgRFn5nqbn2PsR8lQLgTsnZG5aTtEpLdPGnVrPLS4+XE9D3qzgecwEcsbFNWMwJV sLdXLmiDGlERjLXz/rW4+A+bL8Nh9QA2BRLpQEo+s04x0ohplvAYJ42aljliEyCK0u pcmcQOgYXEo8gdTWeQU2v/BSzBLrcNZvKgJuEvPk= Message-ID: <50A7E138.9090601@etorok.net> Date: Sat, 17 Nov 2012 21:10:48 +0200 From: =?windows-1252?Q?T=F6r=F6k_Edwin?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121027 Icedove/10.0.10 MIME-Version: 1.0 To: caml-list@inria.fr References: <70435661-3754-4815-9EEF-B52F33D29B5F@inria.fr> <0BEF3A04-3297-4084-BE4D-13ACCC4D431E@inria.fr> In-Reply-To: <0BEF3A04-3297-4084-BE4D-13ACCC4D431E@inria.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.6 at mail X-Virus-Status: Clean Subject: Re: [Caml-list] Segfault in C++ stub with many 'new' allocations On 11/17/2012 08:42 PM, Samuel Hornus wrote: > > On 17 nov. 2012, at 19:35, Kakadu wrote: > >> 2) AFAIR there are functions like register_global_root which prevents GC from moving values. > > Thank you Kakadu. It is interesting to know that one can use this function directly. I knew its existence only through the CAML[x]param* macros… > > Regarding my first question, if it can help, here is the relevant part of my C++ code: > extern "C" value ann_create_bd_tree_flat_ba (value ba, value n, value dim) > { > CAMLparam3(ba,n,dim); > ANNbd_tree * ptr = create_bd_tree_flat((ANNcoord*)Caml_ba_data_val(ba), Int_val(n), Int_val(dim)); > CAMLreturn ((value)ptr); I don't think this is safe. Shouldn't the return value be wrapped in a custom block? If the GC tries to interpret this as an OCaml value (which it isn't) it might crash. --Edwin