mg5amcnlo / mg5amcnlo

Other
58 stars 32 forks source link

Fix memory leak in madevent_driver.f (close file dname.mg) #110

Closed valassi closed 1 week ago

valassi commented 1 week ago

This fixes memory leak #109 in madevent_driver.f (close file dname.mg)

See https://github.com/madgraph5/madgraph4gpu/issues/868

Without this, valgrind shows

==3682257== 
==3682257== HEAP SUMMARY:
==3682257==     in use at exit: 552 bytes in 3 blocks
==3682257==   total heap usage: 137,537 allocs, 137,534 frees, 48,779,094 bytes allocated
==3682257== 
==3682257== 544 (32 direct, 512 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3
==3682257==    at 0x719786F: malloc (vg_replace_malloc.c:381)
==3682257==    by 0x7404CC8: ??? (in /usr/lib64/libgfortran.so.5.0.0)
==3682257==    by 0x7647C63: ??? (in /usr/lib64/libgfortran.so.5.0.0)
==3682257==    by 0x7635319: ??? (in /usr/lib64/libgfortran.so.5.0.0)
==3682257==    by 0x76357FC: _gfortran_st_open (in /usr/lib64/libgfortran.so.5.0.0)
==3682257==    by 0x47AA9F: open_file_ (open_file.f:40)
==3682257==    by 0x432C91: MAIN__ (driver.f:151)
==3682257==    by 0x40268E: main (driver.f:301)
==3682257== 
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   obj:/usr/lib64/libgfortran.so.5.0.0
   obj:/usr/lib64/libgfortran.so.5.0.0
   obj:/usr/lib64/libgfortran.so.5.0.0
   fun:_gfortran_st_open
   fun:open_file_
   fun:MAIN__
   fun:main
}

After adding this fix, I checked that the warning disappears

@oliviermattelaer can you please review? Thanks Andrea

oliviermattelaer commented 1 week ago

Hi Andrea,

I have look at this, made some check, and this is perfect. In principle this should have target 3.6.0 branch directly (or even 2.9.20 branch) since this is orthogonal to gpucpp. But I think it is fine to include this first in gpucpp and gpucpp_june24

Cheers,

Olivier

valassi commented 1 week ago

Thanks Olivier! Ok I will merge this PR, so it will go into gpucpp. I will also merge PR #112

I let you take care of gpucpp_june24 instead...