Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26746 Discussions

Leaking memory from derived-type array in fortran

Ahmad_S_
Beginner
125 Views

I am using derived-type array in fortran. I ran the executable through valgrind and realized that I am leaking memory. After poking around, I realized that the leaking is related to a compiler flag '-qopenmp'. If this flag is used with intel15, valgrind detects memory leak.

Here is the relevant part of valgrind report when I use intel15 with '-qopenmp' flag:

==84663== 12 bytes in 2 blocks are indirectly lost in loss record 1 of 3
==84663==    at 0x4C26B0D: malloc (vg_replace_malloc.c:296)
==84663==    by 0x40BE9F: for_alloc_allocatable (in /work-zfs/sghosh20/shahba/PaperPhaseField/notFinalized/polycrystalline/testLeak/a.out)
==84663==    by 0x402CDD: classdynamicintegerarray2d_mp_allocate_dynamicintegerarray2d_ (ClassDynamicIntegerArray2d.f90:173)
==84663==    by 0x40329F: allocatewithintent_ (allocateWithIntent.f90:97)
==84663==    by 0x4034E2: MAIN__ (main.f90:82)
==84663==    by 0x40299D: main (in /work-zfs/sghosh20/shahba/PaperPhaseField/notFinalized/polycrystalline/testLeak/a.out)
==84663==
==84663== 32 bytes in 1 blocks are still reachable in loss record 2 of 3
==84663==    at 0x4C28884: calloc (vg_replace_malloc.c:623)
==84663==    by 0x5BB930F: _dlerror_run (dlerror.c:142)
==84663==    by 0x5BB9079: dlsym (dlsym.c:71)
==84663==    by 0x41809E: for__aio_init (in /work-zfs/sghosh20/shahba/PaperPhaseField/notFinalized/polycrystalline/testLeak/a.out)
==84663==    by 0x405FCE: for_rtl_init_ (in /work-zfs/sghosh20/shahba/PaperPhaseField/notFinalized/polycrystalline/testLeak/a.out)
==84663==    by 0x402998: main (in /work-zfs/sghosh20/shahba/PaperPhaseField/notFinalized/polycrystalline/testLeak/a.out)
==84663==
==84663== 156 (144 direct, 12 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3
==84663==    at 0x4C26B0D: malloc (vg_replace_malloc.c:296)
==84663==    by 0x40BE9F: for_alloc_allocatable (in /work-zfs/sghosh20/shahba/PaperPhaseField/notFinalized/polycrystalline/testLeak/a.out)
==84663==    by 0x402B40: classdynamicintegerarray2d_mp_allocate_dynamicintegerarray2d_ (ClassDynamicIntegerArray2d.f90:172)
==84663==    by 0x40329F: allocatewithintent_ (allocateWithIntent.f90:97)
==84663==    by 0x4034E2: MAIN__ (main.f90:82)
==84663==    by 0x40299D: main (in /work-zfs/sghosh20/shahba/PaperPhaseField/notFinalized/polycrystalline/testLeak/a.out)
==84663==
==84663== LEAK SUMMARY:
==84663==    definitely lost: 144 bytes in 1 blocks
==84663==    indirectly lost: 12 bytes in 2 blocks
==84663==      possibly lost: 0 bytes in 0 blocks
==84663==    still reachable: 32 bytes in 1 blocks
==84663==         suppressed: 0 bytes in 0 blocks

 

However if I use intel 17, valgrind detects possible memory leak if I don't use this flag. Here is the relevant part of valgrind report when I use intel17 without '-qopenmp' flag:

 

==85454== 92 bytes in 2 blocks are possibly lost in loss record 2 of 3
==85454==    at 0x4C26B0D: malloc (vg_replace_malloc.c:296)
==85454==    by 0x4695FB: _mm_malloc (in /work-zfs/sghosh20/shahba/PaperPhaseField/notFinalized/polycrystalline/testLeak/a.out)
==85454==    by 0x409A75: for_allocate (in /work-zfs/sghosh20/shahba/PaperPhaseField/notFinalized/polycrystalline/testLeak/a.out)
==85454==    by 0x403382: classdynamicintegerarray2d_mp_allocate_dynamicintegerarray2d_ (ClassDynamicIntegerArray2d.f90:173)
==85454==    by 0x403A05: allocatewithintent_ (allocateWithIntent.f90:97)
==85454==    by 0x403BC4: MAIN__ (main.f90:82)
==85454==    by 0x402F8D: main (in /work-zfs/sghosh20/shahba/PaperPhaseField/notFinalized/polycrystalline/testLeak/a.out)
==85454==
==85454== 184 bytes in 1 blocks are possibly lost in loss record 3 of 3
==85454==    at 0x4C26B0D: malloc (vg_replace_malloc.c:296)
==85454==    by 0x4695FB: _mm_malloc (in /work-zfs/sghosh20/shahba/PaperPhaseField/notFinalized/polycrystalline/testLeak/a.out)
==85454==    by 0x409A75: for_allocate (in /work-zfs/sghosh20/shahba/PaperPhaseField/notFinalized/polycrystalline/testLeak/a.out)
==85454==    by 0x40312D: classdynamicintegerarray2d_mp_allocate_dynamicintegerarray2d_ (ClassDynamicIntegerArray2d.f90:172)
==85454==    by 0x403A05: allocatewithintent_ (allocateWithIntent.f90:97)
==85454==    by 0x403BC4: MAIN__ (main.f90:82)
==85454==    by 0x402F8D: main (in /work-zfs/sghosh20/shahba/PaperPhaseField/notFinalized/polycrystalline/testLeak/a.out)
==85454==
==85454== LEAK SUMMARY:
==85454==    definitely lost: 0 bytes in 0 blocks
==85454==    indirectly lost: 0 bytes in 0 blocks
==85454==      possibly lost: 276 bytes in 3 blocks
==85454==    still reachable: 32 bytes in 1 blocks
==85454==         suppressed: 0 bytes in 0 blocks

 

I am attaching a simple code that mimics this error. To compile the code, please run the compile.sh script.

0 Kudos
1 Reply
Ahmad_S_
Beginner
125 Views

There seems to be no leak, after all. I realized if I deallocate the derived-type arrays at the end of the program, valgrind reports no memory leak , no matter which compiler is used or whether '-qopenmp' is used or not.

Reply