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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable 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!news1.google.com!news.glorb.com!easynet-quince!easynet.net!teaser.fr!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Memory leak - What the ...? Date: 12 Oct 2004 20:12:47 -0400 Organization: Cuivre, Argent, Or Message-ID: References: NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: melchior.cuivre.fr.eu.org 1097626384 17517 212.85.156.195 (13 Oct 2004 00:13:04 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Wed, 13 Oct 2004 00:13:04 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: g2news1.google.com comp.lang.ada:5113 Date: 2004-10-12T20:12:47-04:00 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. > That's the reason I firstly stated the test case was leaking. Too > fast jump to conclusions. But linking with -lgmem and running the > post-mortem gnatmem > > gnatmem 10 -i gmem.out test.exe > > I get: > > Global information > ------------------ > Total number of allocations :3001 > Total number of deallocations :3000 > Final Water Mark (non freed mem) : 24 Bytes > High Water Mark : 499.05 Kilobytes > > Allocation Root # 1 > ------------------- > Number of non freed allocations : 1 > Final Water Mark (non freed mem) : 24 Bytes > High Water Mark : 24 Bytes > Backtrace : > a-except.adb:1289 ada.exceptions.process_raise_exception > a-except.adb:2638 > b~test.adb:106 adainit > b~test.adb:189 main > > Which is consistent. Ok. > I've placed traces in adjust and finalize and they're called as > expected (some of you have already reproduced this). > > 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. > Since we can agree that the implementation is right, I must be doing > something different in my program which this test case doesn't show. > I'll try to summarize all accesses to this type for you, or better > still to get a faultly test case. > > I started this bug chase because I have a program which apparently > runs fine but that after 24 hours of uptime starts to bog down a > server (not under my control, one in which I can't get memory usage) > so it seems plausible that the leak is making it to swap like crazy. I > didn't suspect of a leak until I observed it in windows, and I haven't > been back to linux since. This could also be heap fragmentation, rather than a leak. -- -- Stephe