Detecting memory leaks with gfortran?

Hello,

I am wondering if gfortran provides an option to report memory leaks at
runtime, like g95 did (implicitely) in the past:

program test
real(kind=4), pointer :: a(
!
allocate(a(1000))
a => null()
allocate(a(1000))
deallocate(a)
end program test

g95 output at the end of execution:

Remaining memory: 4000 bytes at 000000000bf56338 allocated at line 4 of
test.f90

I found this thread where a patch is proposed, but can not find it in
the gfortran (4.7.0) options:
http://gcc.gnu.org/ml/fortran/2008-11/msg00380.html

Any idea?

Thanks.

On 02/07/2012 01:34 PM, Sebastien Bardeau wrote:
> I am wondering if gfortran provides an option to report memory leaks at
> runtime, like g95 did (implicitely) in the past:
>
> g95 output at the end of execution:
>
> Remaining memory: 4000 bytes at 000000000bf56338 allocated at line 4 of
> test.f90
>
> I found this thread where a patch is proposed, but can not find it in
> the gfortran (4.7.0) options

I think there were some issues with the patch. It is still planed to
support it eventually, but it has not yet been implemented.

However, you can use valgrind to find memory leaks, available at
http://valgrind.org/ (It should work on all common platforms but
Windows.) As it is frequently used during development, there shouldn't
be any valgrind warnings or memory leaks due to the compiler itself.
(Except for some known issues with polymorphic variables.)

Tobias

Le 02/07/2012 02:01 PM, Tobias Burnus a écrit :
> On 02/07/2012 01:34 PM, Sebastien Bardeau wrote:
>> I am wondering if gfortran provides an option to report memory leaks at
>> runtime, like g95 did (implicitely) in the past:
>>
>> g95 output at the end of execution:
>>
>> Remaining memory: 4000 bytes at 000000000bf56338 allocated at line 4 of
>> test.f90
>>
>> I found this thread where a patch is proposed, but can not find it in
>> the gfortran (4.7.0) options
>
> I think there were some issues with the patch. It is still planed to
> support it eventually, but it has not yet been implemented.
>
> However, you can use valgrind to find memory leaks, available at
> http://valgrind.org/ (It should work on all common platforms but
> Windows.) As it is frequently used during development, there shouldn't
> be any valgrind warnings or memory leaks due to the compiler itself.
> (Except for some known issues with polymorphic variables.)

Indeed, Valgrind... A quick run shows me that it is probably a bit too
much for me. In particular it tracks the memory leaks in the system or
external libraries my program in linked against. Ok it can probably be
tuned, but this will take time to learn.

I would have prefered a simple way to detect leaks in the libraries I
compiled with the check enabled. As g95 did... So if you wonder if
gfortran should provide or not such an option, I vote yes!

Thanks for your help.

Sebastien Bardeau writes:

> Le 02/07/2012 02:01 PM, Tobias Burnus a écrit :
>> On 02/07/2012 01:34 PM, Sebastien Bardeau wrote:
>>> I am wondering if gfortran provides an option to report memory leaks at
>>> runtime, like g95 did (implicitely) in the past:
>>>
>>> g95 output at the end of execution:
>>>
>>> Remaining memory: 4000 bytes at 000000000bf56338 allocated at line 4 of
>>> test.f90
>>>
>>> I found this thread where a patch is proposed, but can not find it in
>>> the gfortran (4.7.0) options
>>
>> I think there were some issues with the patch. It is still planed to
>> support it eventually, but it has not yet been implemented.
>>
>> However, you can use valgrind to find memory leaks, available at
>> http://valgrind.org/ (It should work on all common platforms but
>> Windows.) As it is frequently used during development, there shouldn't
>> be any valgrind warnings or memory leaks due to the compiler itself.
>> (Except for some known issues with polymorphic variables.)
>
> Indeed, Valgrind... A quick run shows me that it is probably a bit too
> much for me. In particular it tracks the memory leaks in the system or
> external libraries my program in linked against. Ok it can probably be
> tuned, but this will take time to learn.

What about ignoring all notifications not concerning your code directly?
With --track-origins=yes you just see where the allocations were made.

--
Alberto