Re: Tracking Memory leak
From: *** Hendrickson (***.hendrickson_at_att.net)
Date: 02/21/05
- Next message: Richard Maine: "Re: Components of derived types with pointer attributes"
- Previous message: Tim Prince: "Re: PGI Preprocessor problems"
- In reply to: Jason Nielsen: "Tracking Memory leak"
- Next in thread: Jason Nielsen: "Re: Tracking Memory leak"
- Reply: Jason Nielsen: "Re: Tracking Memory leak"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 21 Feb 2005 16:19:55 GMT
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.
*** 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
- Next message: Richard Maine: "Re: Components of derived types with pointer attributes"
- Previous message: Tim Prince: "Re: PGI Preprocessor problems"
- In reply to: Jason Nielsen: "Tracking Memory leak"
- Next in thread: Jason Nielsen: "Re: Tracking Memory leak"
- Reply: Jason Nielsen: "Re: Tracking Memory leak"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]