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
|
|
|
|
|