From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 86B79BBAF for ; Fri, 11 Jul 2008 17:56:38 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADUfd0hQRFuw/2dsb2JhbACvNg X-IronPort-AV: E=Sophos;i="4.30,346,1212357600"; d="scan'208";a="15034733" Received: from furbychan.cocan.org ([80.68.91.176]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 11 Jul 2008 17:56:38 +0200 Received: from rich by furbychan.cocan.org with local (Exim 4.63) (envelope-from ) id 1KHKz6-0001OY-3V; Fri, 11 Jul 2008 16:56:36 +0100 Date: Fri, 11 Jul 2008 16:56:36 +0100 To: Sean Seefried Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Heaps size problems with "caml_alloc_small" in foreign function interfaces Message-ID: <20080711155635.GA5107@annexia.org> References: <20080711094050.GB24400@annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: Richard Jones X-Spam: no; 0.00; alloc:01 alloc:01 camlidl:01 verbose:01 initialized:01 garbage:01 wrote:01 caml-list:01 functions:01 functions:01 interfaces:01 explicitly:02 caml:02 caml:02 interpret:03 On Fri, Jul 11, 2008 at 08:21:45PM +1000, Sean Seefried wrote: > caml_alloc_small(32,0); > > is what seemed to cause the problem. I'm shying away from posting more > code since it is auto-generated from CamlIDL and is very verbose. I > didn't write it myself. You need to post a reproducer. > >Secondly (and much more likely to be the problem), the caml_alloc* > >functions allocate uninitialised memory. If the garbage collector > > What do you mean by "uninitialised memory"? Memory which hasn't been explicitly initialized, and so contains random stuff. The GC attempts to interpret the random stuff and fails. [...] > What do you do about this? Is there a way to stop the GC from running > for a period of time? The GC could possibly run any time you call an allocation function. So don't call allocation functions. Anyhow, you really need to post some code at this point. Rich. -- Richard Jones Red Hat