Auto-testing for memory leaks.

Hello,

I have a bunch of derived types that contain pointer arrays. In the course of their use
the structures get allocated, copied, destroyed, reallocated, extended, etc.

I test for memory leaks in a rather brain dead way - I call the routines in my test code
many 10's of 1000's of times with top running in another window so I can keep an eye on
the memory usage. If it increases steadily, I have a leak.

But, I was wondering if anyone out there had any smarter ideas for testing this? Needing
to run top alongside doesn't make for a very easy to use test.

Thanks for any ideas.

cheers,

paulv

On Sep 5, 11:09*am, Paul van Delst <Paul.vanDe...@noaa.gov> wrote:
> Hello,
>
> I have a bunch of derived types that contain pointer arrays. In the course of their use
> the structures get allocated, copied, destroyed, reallocated, extended, etc.
>
> I test for memory leaks in a rather brain dead way - I call the routines in my test code
> many 10's of 1000's of times with top running in another window so I can keep an eye on
> the memory usage. If it increases steadily, I have a leak.
>
> But, I was wondering if anyone out there had any smarter ideas for testing this? Needing
> to run top alongside doesn't make for a very easy to use test.
>
> Thanks for any ideas.
>
> cheers,
>
> paulv

You should be using Valgrind (http://valgrind.org)

On Sep 5, 11:44*am, rusi_pathan <tabrez...@gmail.com> wrote:
> On Sep 5, 11:09*am, Paul van Delst <Paul.vanDe...@noaa.gov> wrote:
>
>
>
> > Hello,
>
> > I have a bunch of derived types that contain pointer arrays. In the course of their use
> > the structures get allocated, copied, destroyed, reallocated, extended,etc.
>
> > I test for memory leaks in a rather brain dead way - I call the routines in my test code
> > many 10's of 1000's of times with top running in another window so I can keep an eye on
> > the memory usage. If it increases steadily, I have a leak.
>
> > But, I was wondering if anyone out there had any smarter ideas for testing this? Needing
> > to run top alongside doesn't make for a very easy to use test.
>
> > Thanks for any ideas.
>
> > cheers,
>
> > paulv
>
> You should be using Valgrind (http://valgrind.org)

Btw it is already available in many linux distributions. It certainly
is in Debian so installation is a snap.

And here's small example:

program main
implicit none
real, pointer :: p(
allocate(p(5))
call random_number(p)
print*, p
!deallocate(p)
nullify(p)
end program


$ gfortran -g example.f90
$ valgrind --leak-check=yes ./a.out
....
==7212== LEAK SUMMARY:
==7212== definitely lost: 20 bytes in 1 blocks.
....


If you deallocate p then

$ gfortran -g example.f90
$ valgrind --leak-check=yes ./a.out
....
All heap blocks were freed -- no leaks are possible.
....

Paul van Delst wrote:
> Hello,
>
> I have a bunch of derived types that contain pointer arrays. In the
> course of their use the structures get allocated, copied, destroyed,
> reallocated, extended, etc.
>
> I test for memory leaks in a rather brain dead way - I call the routines
> in my test code many 10's of 1000's of times with top running in another
> window so I can keep an eye on the memory usage. If it increases
> steadily, I have a leak.
>
> But, I was wondering if anyone out there had any smarter ideas for
> testing this? Needing to run top alongside doesn't make for a very easy
> to use test.
>
> Thanks for any ideas.
>
> cheers,
>
> paulv
You could use /proc filesystem. On Linux, that would be a virtual ascii
file /proc/<pid>/status, inn which the lines starting with Vm are of
iterest. On CCS IBM, /proc/<pid> requires a system library to make sense
of it. I once started writing such thing, but never finished. But this
is doable.
In general, the solution has to be OS dependent.

George

Paul van Delst wrote:
> Hello,
>
> I have a bunch of derived types that contain pointer arrays. In the
> course of their use the structures get allocated, copied, destroyed,
> reallocated, extended, etc.
>
> I test for memory leaks in a rather brain dead way - I call the routines
> in my test code many 10's of 1000's of times with top running in another
> window so I can keep an eye on the memory usage. If it increases
> steadily, I have a leak.
>
> But, I was wondering if anyone out there had any smarter ideas for
> testing this? Needing to run top alongside doesn't make for a very easy
> to use test.
>
> Thanks for any ideas.

Apologies for replying to my own post, but our news server has been very spotty of late so
I haven't received any replies locally and have been checking google groups.

To the poster rusi_pathan: thankyouthankyouthankyou! )

I went to the valgrind page, downloaded it, discovered it was already installed on my
linux system, recompiled my test prog, used the memchecker, and got immediate detailed
results! No memory leaks. Woohoo! I even deliberately buggered up my code to leak memory,
re-ran and there it was:

==26613== 41,600 bytes in 52 blocks are definitely lost in loss record 3 of 13
==26613== at 0x4004405: malloc (vg_replace_malloc.c:149)
==26613== by 0x805E3C6: __crtm_atmosphere_define_MOD_allocate_scalar
(CRTM_Atmosphere_Define.f90:1269)
==26613== by 0x806FB68: __crtm_atmosphere_binary_io_MOD_read_record
(CRTM_Atmosphere_Binary_IO.f90:1088)
==26613== by 0x8075D60: __crtm_atmosphere_binary_io_MOD_read_atmosphere_ra nk1
(CRTM_Atmosphere_Binary_IO.f90:438)
==26613== by 0x808B40B: MAIN__ (Test_Atmosphere.f90:407)
==26613== by 0x808B73D: main (fmain.c:21)
....etc...

Crikey! What a great tool! How come I never tried this before? I can't wait to try the
profiler!

Cheers... and thanks again.

paulv

On 2008-09-05, Paul van Delst <Paul.vanDelst@noaa.gov> wrote:
> Hello,
>
> I have a bunch of derived types that contain pointer arrays. In the course of their use
> the structures get allocated, copied, destroyed, reallocated, extended, etc.
>
> I test for memory leaks in a rather brain dead way - I call the routines in my test code
> many 10's of 1000's of times with top running in another window so I can keep an eye on
> the memory usage. If it increases steadily, I have a leak.
>
> But, I was wondering if anyone out there had any smarter ideas for testing this? Needing
> to run top alongside doesn't make for a very easy to use test.
>
> Thanks for any ideas.

Like rusi_pathan already mentioned, if you're on Linux valgrind is
double plus awesome. The downside is that it slows down the program a
lot, so you probably need to run it with some small test data set rather
than production input.


--
JayBee

JayBee wrote:
> On 2008-09-05, Paul van Delst <Paul.vanDelst@noaa.gov> wrote:
>> Hello,
>>
>> I have a bunch of derived types that contain pointer arrays. In the course of their use
>> the structures get allocated, copied, destroyed, reallocated, extended, etc.
>>
>> I test for memory leaks in a rather brain dead way - I call the routines in my test code
>> many 10's of 1000's of times with top running in another window so I can keep an eye on
>> the memory usage. If it increases steadily, I have a leak.
>>
>> But, I was wondering if anyone out there had any smarter ideas for testing this? Needing
>> to run top alongside doesn't make for a very easy to use test.
>>
>> Thanks for any ideas.
>
> Like rusi_pathan already mentioned, if you're on Linux valgrind is
> double plus awesome. The downside is that it slows down the program a
> lot, so you probably need to run it with some small test data set rather
> than production input.

What about on Windoze?

> But, I was wondering if anyone out there had any smarter ideas for
> testing this? Needing to run top alongside doesn't make for a very easy
> to use test.

Another alternative is to use a malloc() implementation that does
garbage collection. I have once used an early version of the Sun
compiler that contained such (from a company called Great Circle, IIRC).
It had a web-based interface that showed you statistics, including some
about memory leaks. For anything but trivial programs, its use was
required - the RTL implementation had too many leaks that would
otherwise have stopped the running program.

The advantage of garbage collection over approaches such as VALGRIND are
that they introduce no additional overhead compared to doing without.

Jan