- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The following code results in a memory leak when compiled with ifort 14.0.3
module testmod type :: obj integer, allocatable :: i contains procedure :: add => obj_add procedure :: copy => obj_copy generic :: operator(+) => add end type obj contains subroutine obj_copy(this, source) implicit none class(obj) :: this class(obj) :: source this%i=source%i end subroutine obj_copy function obj_add(A, B) result(C) implicit none class(obj), intent(in) :: A, B class(obj), allocatable :: C allocate(C) allocate(C%i) C%i=A%i+B%i end function obj_add end module testmod program leak use testmod implicit none class(obj), allocatable :: A, B, C allocate(A, B, C) A%i=1 B%i=2 call C%copy(A+B) deallocate(A, B, C) end program leak
When compiled with
ifort -g -o leak leak.f90 -assume realloc_lhs
Valgrind reports
==21260== 4 bytes in 1 blocks are definitely lost in loss record 1 of 2
==21260== at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21260== by 0x419BF8: for_alloc_allocatable (in /mnt/data/PhD/Fortran/bugs/operator-leak/leak)
==21260== by 0x402F41: testmod_mp_obj_add_ (leak.f90:26)
==21260== by 0x403431: MAIN__ (leak.f90:39)
==21260== by 0x402BC5: main (in /mnt/data/PhD/Fortran/bugs/operator-leak/leak)
think this might also be the cause of the problems encountered in this thread https://software.intel.com/en-us/forums/topic/487142 from some time ago.
If I change the result dummy to
type(obj) :: C
and skip the allocation stuff in obj_add, then the leak is avoided. However, this also results in losing polymorphism, which is undesirable. If the procedure is made as a subroutine, I lose the ability to use it as an operator. Does anybody have any suggestion to work around this issue?
Best regards
Emil Sørensen
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I will investigate this issue Emil and post an update shortly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I reproduced your findings and see the same results for newer compilers and reported this to Development (see internal tracking id below) for further investigation. I will update the post with information about any work around and status as I learn it.
(Internal tracking id: DPD200358323)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you very much Kevin, I appreciate it. This leak has really proven to be a show-stopper for my implementation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Emil S. wrote:
Thank you very much Kevin, I appreciate it. This leak has really proven to be a show-stopper for my implementation.
Emil,
Would you be interested in running your code example through Intel Inspector for Linux (if you don't have a license, you can check with Intel staff about being getting a free evaluation license to their 2015 BETA version) and see whether it can catch the same memory leak that Valgrind found? If yes, I'll be interested in learning from your findings.
Thanks,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi FortranFan
I am unfamiliar with the Intel Inspector, but I have downloaded an evaluation copy of Intel Inspector XE 2013 and gave it a try. This is what I obtained
$ inspxe-cl -version
Intel(R) Inspector XE 2013 Update 9 (build 328075) Command Line tool
Copyright (C) 2009-2013 Intel Corporation. All rights reserved.
$ inspxe-cl -collect mi3 -knob analyze-stack=false -knob detect-leaks-on-exit=true -knob enable-memory-growth-detection=true -knob enable-on-demand-leak-detection=true -knob remove-duplicates=true -knob still-allocated-memory=true -knob stack-depth=16 -module-filter-mode=include -appdebug=off -- /mnt/data/PhD/Fortran/bugs/operator-leak/leak
1 new problem(s) found
1 Memory leak problem(s) detected
$ inspxe-cl -report problems -result-dir r000mi3/
P1: Error: Memory leak
P1.3: Memory leak: 4 Bytes: New
/mnt/data/PhD/Fortran/bugs/operator-leak/leak.f90(26): Error X3: Allocation site: Function obj_add: Module /mnt/data/PhD/Fortran/bugs/operator-leak/leak$
So as far as I can tell, Intel Inspector finds the same memory leak as Valgrind did.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Emil S. wrote:
...
So as far as I can tell, Intel Inspector finds the same memory leak as Valgrind did.
Thank you very much - greatly appreciate your post. I'll follow-up on my installation of Intel Inspector and check why I don't get the same response. By the way, I work mainly on Windows platform (our sole Linux box has been unavailable for a while) and am experiencing similar issues with memory leaks with user-defined operators in Fortran 2003/2008 code. I've been playing around with Intel Inspector on Windows 2015 Beta since Valgrind is unavailable on Windows; I'm not having much luck with Inspector finding leaks even though Dr. Memory (another tool) says there are leaks. Hence my request to you to do the checking with Inspector on Linux.
Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No problem FortranFan, glad I could help :)

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page