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!news4.google.com!news.glorb.com!newsfeed.stueberl.de!news-mue1.dfn.de!news-lei1.dfn.de!news.uni-jena.de!not-for-mail From: Christopher Broeg Newsgroups: comp.lang.ada Subject: Re: many exceptions cause memory leak? Date: Tue, 25 Oct 2005 09:32:20 +0200 Organization: Friedrich Schiller University Jena, Germany Message-ID: References: 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 1130225543 12050 141.35.25.76 (25 Oct 2005 07:32:23 GMT) X-Complaints-To: abuse@uni-jena.de NNTP-Posting-Date: Tue, 25 Oct 2005 07:32:23 +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: Xref: g2news1.google.com comp.lang.ada:5917 Date: 2005-10-25T09:32:20+02:00 List-Id: Simon Wright wrote: > Christopher Broeg writes: > >>I am by no means an expert in programming but I figured that all >>memory assigned by pointers is returned. I do not use my own storage >>pool but allocate just by >>is new... >>so it is all on the heap, I guess. > > GNAT doesn't automatically free this memory until the end of the > program. You need to free it yourself. I do use unchecked deallocation on all pointers. I now have used gnatmem and found one memory leak that was my fault. There are still a few thousand "leaks" due to ada exception handling, though. Gnatmem output follows: 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 Allocation Root # 1 ------------------- Number of non freed allocations :12702 Final Water Mark (non freed mem) : 80.87 Kilobytes High Water Mark : 80.87 Kilobytes Backtrace : a-except.adb:1396 I do think that the program now stays constnat in size, or at least asymtotically approaches a relatively small constant size in memory. running the code over night, the high water mark of the entire program was small, so I hope the problem is solved. But since the program had already finished by this morning, I couldn't check independently using top, also I could not check whether this means reserved memory only and what happens with the virtual memory. It used to be twice as large as the reserved. I'll know in another 10 hours if everything is fine now. Still, I am wondering if the above begaviour is normal. It is only 60kB, so no big deal, but 12702 non freed allocations? Is this normal? They always stem from line 1396 in a-except.adb. It is the place where a dummy procecdure called ZZZ is called. It appears to me that this should be a one-time per program lifetime event. Does this mean that there are 12702 somehow independent exception occurences in my program? thanks for all your help, Chris