Re: Memory leak - What the ...?

[Stephen Leake <stephen_leake@acm.org>]

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
> 
> <snip of stacktraces>
> 
> 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 <ada__exceptions___elabb>
>    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