grimme-lab
Memory leaks from opening files
Describe the bug Valgrind detects memory leaks when running xTB, either through the executable or the C API. There are a decent number of these even just for a plain single point energy calculation and possibly more for specific calculations types, but in this issue I'm focusing on a leak that seems the most general. Here is the valgrind output:
==00:00:00:03.793 2197== 43 bytes in 1 blocks are possibly lost in loss record 24 of 235
==00:00:00:03.793 2197== at 0x40397DB: malloc (vg_replace_malloc.c:431)
==00:00:00:03.793 2197== by 0x70246EF: _mm_malloc (in /software/lib/Linux-x86_64/ifort_2022.0.2/compiler/lib/intel64_lin/libirc.so)
==00:00:00:03.793 2197== by 0x731C078: for_allocate_handle (in /software/lib/Linux-x86_64/ifort_2022.0.2/compiler/lib/intel64_lin/libifcore.so.5)
==00:00:00:03.793 2197== by 0x72B7A1C: do_alloc_copy (in /software/lib/Linux-x86_64/ifort_2022.0.2/compiler/lib/intel64_lin/libifcore.so.5)
==00:00:00:03.793 2197== by 0x72B9039: do_alloc_copy (in /software/lib/Linux-x86_64/ifort_2022.0.2/compiler/lib/intel64_lin/libifcore.so.5)
==00:00:00:03.793 2197== by 0x72BA8A6: for_alloc_assign_v2 (in /software/lib/Linux-x86_64/ifort_2022.0.2/compiler/lib/intel64_lin/libifcore.so.5)
==00:00:00:03.793 2197== by 0x5F26D9: xtb_type_iohandler_mp_pushback_ (in /software/lib/Linux-x86_64/xtb-d42779f-XTB-42/bin/xtb)
==00:00:00:03.793 2197== by 0x5F3B7B: xtb_type_iohandler_mp_writefile_ (in /software/lib/Linux-x86_64/xtb-d42779f-XTB-42/bin/xtb)
==00:00:00:03.793 2197== by 0x69DBEA: open_file_ (in /software/lib/Linux-x86_64/xtb-d42779f-XTB-42/bin/xtb)
==00:00:00:03.793 2197== by 0x5489CB: xtb_propertyoutput_mp_main_property_ (in /software/lib/Linux-x86_64/xtb-d42779f-XTB-42/bin/xtb)
==00:00:00:03.793 2197== by 0x424E7A: xtb_prog_main_mp_xtbmain_ (in /software/lib/Linux-x86_64/xtb-d42779f-XTB-42/bin/xtb)
==00:00:00:03.793 2197== by 0x433B81: MAIN__ (in /software/lib/Linux-x86_64/xtb-d42779f-XTB-42/bin/xtb)
==00:00:00:03.793 2197== by 0x4061A1: main (in /software/lib/Linux-x86_64/xtb-d42779f-XTB-42/bin/xtb)
==00:00:00:03.793 2197==
There are others with slightly different stack traces, but the commonality seems to be the call to open_file and the subsequent copies that lead to leaked allocations.
Note: these leaks haven't caused any apparent problems with xTB runs, but they are likely still useful to address in the long term.
To Reproduce
With xTB-6.7.1 (in my case compiled with ifort 2022.0.2 and gcc 11.3, but I imagine this could occur with other compilers) run a single point with the executable.
I used the valgrind command: valgrind --tool=memcheck --time-stamp=yes --num-callers=20 --gen-suppressions=all --leak-check=yes --keep-debugi nfo=yes --error-exitcode=29 --log-file=valgrind_memcheck.log xtb methane.sdf --hess
Attached is the log for all memory leaks found during the above hessian calculation valgrind_memcheck.log
Thank you!
It is better to use -g -fsanitize=address -fno-omit-frame-pointer (that is well known flags for AddressSanitizer) for detecting such issues since it will instrument only user's code, not the whole app (user's code + Fortran runtime + system libraries). The memory leak may happen at any place (at least ArmFlang Fortran runtime has memory leaks which I saw).
