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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ec2a500cce3658c4 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews1.google.com!not-for-mail From: mosteo@gmail.com (Alex R. Mosteo) Newsgroups: comp.lang.ada Subject: Re: Memory leak - What the ...? - FOUND Date: 13 Oct 2004 06:11:57 -0700 Organization: http://groups.google.com Message-ID: References: NNTP-Posting-Host: 62.101.166.128 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1097673118 24111 127.0.0.1 (13 Oct 2004 13:11:58 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 13 Oct 2004 13:11:58 +0000 (UTC) Xref: g2news1.google.com comp.lang.ada:5149 Date: 2004-10-13T06:11:57-07:00 List-Id: Stephen Leake wrote in message news:... > mosteo@gmail.com (Alex R. Mosteo) writes: > > > That's it, no leak reported. But running > > > > gnatmem 3 test.exe > > > > I get: > > > > Global information > > ------------------ > > Total number of allocations :6001 > > Total number of deallocations : 0 > > Final Water Mark (non freed mem) : 1.49 Megabytes > > High Water Mark : 1.49 Megabytes > > > > > > > > Which clearly shows... not a single deallocation !? > > SO there's a bug (or feature) in gnatmem on Windows. I suspect GNAT > makes one large request from the OS, and doesn't return it until after > gnatmem finishes. But I'm just guessing. > > > (BTW the result is similar without the Debug_Pool). This is wrong. > > "wrong" by what GNAT reference manual? "not what I expected", perhaps. > "Wrong" requires a clear definition of what is "right", from the > compiler documentation. Wrong in the sense that that's not what's happening, as Debug_Pools and the post-mortem gnatmem show. I guess this is some GDB integration problem, since it is run transparently in this live mode. According to the user guide, the two gnatmem modes should reflect the same behavior: "Both modes produce the very same output." [Gnat UG] > > However, one thing is absolutely true: changing this type by an all > > static one has removed the leak in my full program. > > What leak? > > Use Gnat.Debug_Pools for that, as well. I know that my position is feeble, since I haven't been able to prove the leak. But, my fault (see below) or gnat, there's a leak in my original code :/ After testing with Gnat.Debug_Pools, here are the findings: * gnatmem says the culprit is the Udp_Message.Data member. * Debug_Pool says everything is okay with these allocations (no leak). * ????? > This could also be heap fragmentation, rather than a leak. Would then gnatmem show unreleased allocations? I don't think so. In the course of writing this post (several hours going in and out) I've found the problem. You will want to beat me :( I had already a Debug_Pool in place for the Stream_Element_Array_Access, which is declared in another package, and which I hadn't look at. So there's no leak but the normal operation of the Debug_Pools, which consume memory monotonically up (I already knew this but alas I had not thought of it). Interesting that gnatmem doesn't show any trace of Gnat.Debug_Pools code. Of course, when I was not using this array access, the pool wasn't being used and so the apparent leak dissapeared. I'm very very sorry for having wasted your time. At least some interesting points on Controlled types have been discussed. I certainly have benefited from it. Kind regards, A. Mosteo.