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 B46867ED28 for ; Wed, 6 Jun 2012 23:30:09 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEGANjKz0+wH2GN/2dsb2JhbABFsFyDXYEHghgBAQU4UQsYCRYPCQMCAQIBRRMIAQGIC7hdjguDFgOVHY96gmE X-IronPort-AV: E=Sophos;i="4.75,726,1330902000"; d="scan'208";a="146822504" Received: from arrow.z273.org.uk ([176.31.97.141]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 06 Jun 2012 23:30:09 +0200 Received: from 88-104-228-171.dynamic.dsl.as9105.com ([88.104.228.171] helo=[192.168.1.101]) by arrow.z273.org.uk with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1ScNns-00026E-7n for caml-list@inria.fr; Wed, 06 Jun 2012 22:30:08 +0100 Message-ID: <4FCFCBDA.6010807@z273.org.uk> Date: Wed, 06 Jun 2012 22:30:02 +0100 From: Brian Campbell User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: caml-list@inria.fr References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Fatal error: out of memory Hi, On 05/06/12 01:32, Jianzhou Zhao wrote: > Hi List, > > My program reports "Fatal error: out of memory" as a heisenbug on > 64-bit machine. When I debugged my code or wanted to print any > messages from the code, the error did not appear. Also, on 32-bit > machine, the program has no "out of memory" problem. I found the > message is from "asmrun/memory.c". Does anyone know any clue or hint > to resolve the issue? There's at least one optimisation in the compiler that can affect the memory profile of ocaml programs. If memory serves, "let x = e1 in e2" can become "e2[e1]" where e1 is pure and x appears once, and I think these are sometimes generated for pattern matching where e1 is a projection. This means that the value projected out of might be held for longer than the unoptimised version, increasing the memory usage. I did have a (rather pathological) example of this where the debug version worked but the optimised one ran out of memory, but it was in a large application and I was unable to reproduce it later on. There have been some related changes to the optimisation code in the meantime, so you might benefit from trying the beta version that was just announced. If nothing else, it applies those optimisations when compiling debug versions too, so you might be able to see the failure during debugging.