Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory leaks from opening files #1154

Open
TyBalduf opened this issue Jan 9, 2025 · 0 comments
Open

Memory leaks from opening files #1154

TyBalduf opened this issue Jan 9, 2025 · 0 comments
Labels
unconfirmed This report has not yet been confirmed by the developers

Comments

@TyBalduf
Copy link
Contributor

TyBalduf commented Jan 9, 2025

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

@TyBalduf TyBalduf added the unconfirmed This report has not yet been confirmed by the developers label Jan 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
unconfirmed This report has not yet been confirmed by the developers
Projects
None yet
Development

No branches or pull requests

1 participant