From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,fe0d58e5e40e10c7
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!news2.volia.net!news.germany.com!newsfeed.freenet.de!news-lei1.dfn.de!news.uni-jena.de!not-for-mail
From: Christopher Broeg <broeg@astro.uni-jena.de>
Newsgroups: comp.lang.ada
Subject: Re: many exceptions cause memory leak?
Date: Wed, 26 Oct 2005 12:56:57 +0200
Organization: Friedrich Schiller University Jena, Germany
Message-ID: <djnndp$7kg$1@lc03.rz.uni-jena.de>
References: <djaell$395$1@lc03.rz.uni-jena.de>
 <djigj0$v77$1@lc03.rz.uni-jena.de> <m27jc2bs78.fsf@grendel.local>
 <djkn27$boi$1@lc03.rz.uni-jena.de> <djknki$cl6$1@lc03.rz.uni-jena.de>
 <369da$435e7da8$3ea6010b$8607@news.versatel.net>
NNTP-Posting-Host: ent.astro.uni-jena.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: lc03.rz.uni-jena.de 1130324217 7824 141.35.25.76 (26 Oct 2005
 10:56:57 GMT)
X-Complaints-To: abuse@uni-jena.de
NNTP-Posting-Date: Wed, 26 Oct 2005 10:56:57 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050921
X-Accept-Language: en-us, en
In-Reply-To: <369da$435e7da8$3ea6010b$8607@news.versatel.net>
Xref: g2news1.google.com comp.lang.ada:5953
Date: 2005-10-26T12:56:57+02:00
List-Id: <comp.lang.ada>

Wiljan Derks wrote:
> "Christopher Broeg" <broeg@astro.uni-jena.de> wrote in message 
> news:djknki$cl6$1@lc03.rz.uni-jena.de...
>>>Global information
>>>------------------
>>>   Total number of allocations        :109993
>>>   Total number of deallocations      :97243
>>>   Final Water Mark (non freed mem)   :  29.85 Megabytes
>>>   High Water Mark                    :  29.90 Megabytes
> Still looks like you are loosing memory.
> Maybe a good tip:
> When and exception occurs one can easily asume that an inout variable of a 
> procedure
> alsready has the value assigned to its end location. Thus something like 
> this:
> procedure zzz(x: in out access y) is
> begin
>     x:=new ...
>    exception here
> end;
> When an exception occurs, one could assume that the new pointer is already 
> assigned
> to the structure that was passed to zzz.
> That is however not the case when using gnat.
> Typically, the inout parameter is a local variable for the procedure that is 
> stored on its final location when doing
> a normal procedure exit.
> This is a typical reason for loosing memory when doing exception processing.
> Changing the mode from inout to and access parameter fixes that.
> 
> 
Hi,

the ZZZ procedure is a procedure in the GNAT exception library. There 
are no pointers there, actually.

I think I might have found the reason for the memory loss, though:

I am using unchecked_acces to the data for the external HDF5 calls. The 
memory leak seems to be originating there.

If I have aliased variables do I have to manually free the memory?

i.e. I have:

declare
  Data      : H5_double.Data_1d(0..2) ;
begin
...
Status := H5_Double.H5aread (Attr_Id     => Attribute,
                              Mem_Type_Id => H5t_Native_double,
                              Buf         => Data(0)'Unchecked_Access);



data_1d is an array of aliased float. I don't do any manual deallocaton.

cheers,

Chris