For Programmers: Free Programming Magazines  


Home > Archive > Fortran > February 2005 > Tracking Memory leak









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Tracking Memory leak
Jason Nielsen

2005-02-20, 8:57 pm

Hi all,

Can anyone recommend a tool for tracking memory leaks in f95 code? I have
a rather large piece of code that I have been unable to de-leak... looking
for the usual suspects such as missing deallocate and dangling pointers
has not been successful. I'm using:

Version 7.1 Build 20040901Z

Thanks,
Jason
Jan Vorbrüggen

2005-02-21, 8:57 am

Look whether you can find a library that substitutes the malloc() family
with a garbage collector. At one point, the Sun Fortran compiler came
with such a thing (from Great Circle, IIRC) that also had a report utility
one could access via HTTP. Extremely useful - also in debugging the
compiler's RTL 8-).

Jan
Arnaud Desitter

2005-02-21, 8:57 am


"Jason Nielsen" <jdn@cs.sfu.ca> wrote in message
news:Pine.LNX.4.60.0502201358070.6562@localhost...
> Hi all,
>
> Can anyone recommend a tool for tracking memory leaks in f95 code? I have
> a rather large piece of code that I have been unable to de-leak... looking
> for the usual suspects such as missing deallocate and dangling pointers
> has not been successful. I'm using:
>
> Version 7.1 Build 20040901Z


If you are using Linux x86 so you should give valgrind a go.
Additionally, the NAG compiler has a memory tracing feature that is pretty
neat to find memory leaks.

Regards,


Dick Hendrickson

2005-02-21, 4:01 pm

Two thoughts.

Some compilers leak memory when a function returns either an
array or a pointer to an array. There's not much you can
do about that, other than use a different compiler or
don't return arrays.

Have you tried sprinkling your program with allocate
statements with a STAT= test. Something like
ALLOCATE( should_be_enough_memory(some_size), STAT=I)
if (I .ne. 0) then
print *, " we leaked before we got here"
stop
endif
deallocate (should_be_enough_memory)

If the leak symptom is that you eventually run out of
memory, then experimenting with "some_size" might help
you narrow down the search.

Dick Hendrickson

PS: it would help if you mentioned the compiler brand name,
as well as the version, ("f95" is sort of like "car") and
the operating system.

Jason Nielsen wrote:
> Hi all,
>
> Can anyone recommend a tool for tracking memory leaks in f95 code? I
> have a rather large piece of code that I have been unable to de-leak...
> looking for the usual suspects such as missing deallocate and dangling
> pointers has not been successful. I'm using:
>
> Version 7.1 Build 20040901Z
>
> Thanks,
> Jason


Jason Nielsen

2005-02-21, 4:01 pm

Thanks for the information, any help is useful. The compiler I'm using is
Intel Fortran Version 7.1 Build 20040901Z. I didn't realize I had omitted
the Intel part ;-)! I've been trying to write a little program that
emulates the problem but have been unsuccessful... I thought it had to do
with the way I was using pointers and allocating and deallocating memory
however the following illustrative program doesn't seem to leak. I've
attached in case someone can see something obvious. I just installed
valgrind and gave it a try ... it gives lots of info that I haven't quite
figured out how to use yet. Thanks again for the help.

Cheers,
Jason


module glob
implicit none
real, save, target, allocatable:: A(:,:), B(:,:)
real, pointer:: aa(:,:) => null()
integer:: rw, cl

contains

subroutine init(m,n)
integer, intent(in):: m, n
rw=m
cl=n
allocate(A(m*n,n),B(m*n,n))
A=0.0
end subroutine init

subroutine unload
implicit none
deallocate(A)
end subroutine unload

subroutine do_stuff
implicit none
integer:: i
do i=1,rw
aa=>A(((i-1)*cl+1):(i*cl),:)
aa=1.0
aa=aa+2.0
end do
B=A
! nullify(aa)
end subroutine do_stuff

subroutine looper(n)
implicit none
integer, intent(in):: n
integer:: i
do i=1,n
call do_stuff
end do
end subroutine looper

end module glob

program leak
use glob
implicit none
call init(1000,100)
call looper(10000)
call unload
end program leak

Keith Refson - real email address in signature

2005-02-22, 8:58 am

Jason Nielsen <jdn@cs.sfu.ca> writes:

> Can anyone recommend a tool for tracking memory leaks in f95 code? I
> have a rather large piece of code that I have been unable to
> de-leak... looking for the usual suspects such as missing deallocate
> and dangling pointers has not been successful. I'm using:
>
> Version 7.1 Build 20040901Z


Others have already recommended the valgrind/cachegrind toolset. My
experience is that these don't work with the Intel 7.1 compilers but
do with 8.1, so you may want to consider an upgrade.

But the real purpose of this post is to recommend the g95 compiler.
(http://www.g95.org) which prints a list of leaked memory at the
end of the program run with an indication of the allocation site.

Keith Refson
--
Dr Keith Refson,
Building R3
Rutherford Appleton Laboratory
Chilton
Didcot
Oxfordshire OX11 0QX
T: 01235 778023 K.Refson@
F: 01235 445720 @rl.ac.uk
Arjen Markus

2005-02-22, 8:58 am

Jason Nielsen wrote:
>
> Hi all,
>
> Can anyone recommend a tool for tracking memory leaks in f95 code? I have
> a rather large piece of code that I have been unable to de-leak... looking
> for the usual suspects such as missing deallocate and dangling pointers
> has not been successful. I'm using:
>
> Version 7.1 Build 20040901Z
>
> Thanks,
> Jason


Have you tried with valgrind? It is a wonderful tool for that sort of
things - the only drawback is that it works only on Linux with
Intel-PCs.

Regards,

Arjen
Jason Nielsen

2005-02-22, 4:01 pm

On Tue, 22 Feb 2005, Keith Refson - real email address in signature wrote:

>
>
> Jason Nielsen <jdn@cs.sfu.ca> writes:
>
>
> Others have already recommended the valgrind/cachegrind toolset. My
> experience is that these don't work with the Intel 7.1 compilers but
> do with 8.1, so you may want to consider an upgrade.
>
> But the real purpose of this post is to recommend the g95 compiler.
> (http://www.g95.org) which prints a list of leaked memory at the
> end of the program run with an indication of the allocation site.
>
> Keith Refson
> --
> Dr Keith Refson,
> Building R3
> Rutherford Appleton Laboratory
> Chilton
> Didcot
> Oxfordshire OX11 0QX
> T: 01235 778023 K.Refson@
> F: 01235 445720 @rl.ac.uk
>


Thanks for the pointer to g95. I have been testing this compiler on my
code but never considered using it for debugging given its "in
development" status. Out of curiosity what flag ... a brief glance with
--help didn't list anything that seems correct. I was looking for
something like -C.

As for my memory leak I finally found it. It was actually in one of my
"well testing/trusted" personal libraries... ;-)! It was a case of an
optional argument biting me.... when the optional argument was given the
program would go down the false part of an if-then-else where the
corresponding deallocate() wasn't present.... bugger!

Thanks to all for the helpful advice.

Cheers,
Jason
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com