I am helping someone investigate some problems that seem related to memory issue so I build and ran LAMMPS with clang’s Address Sanitizer. It found a leak, but unfortunately the line number reported definitely seems wrong. I’ve attached the output as asan.txt. Does anyone know if this leak has been fixed since the 30 Jul 2016 release?
Also, asan will only report the first error it encounters and quits, so there may be quite a few more issues not reported.
I ran the same program through valgrind (which takes forever, obviously) and also attached its report. It’s not that helpful but it confirms that there are more leaks.
asan.txt (822 Bytes)
valgrind.txt (682 Bytes)
I am helping someone investigate some problems that seem related to memory
issue so I build and ran LAMMPS with clang's Address Sanitizer. It found a
leak, but unfortunately the line number reported definitely seems wrong.
I've attached the output as asan.txt. Does anyone know if this leak has been
fixed since the 30 Jul 2016 release?
i cannot say for certain. there have been memory leaks fixed since,
but none of them change the function listed in your reports.
it is still worth making a test with the very latest development
version for the reason listed below.
Also, asan will only report the first error it encounters and quits, so
there may be quite a few more issues not reported.
the LAMMPS developers are currently doing a more thorough audit of the
code in preparation for a stable release.
assuming that it is still present, it would be very helpful, if you
could provide us with a simple input that reproduces the leak, as
there is a good chance, that your input may be triggering a condition,
that is not covered by our existing tests (which are quite limited
considering the vast number of features in LAMMPS and the many
variants of how they can be used and combined.
thanks,
axel.
Here are the line numbers:
==3488== 95 bytes in 4 blocks are definitely lost in loss record 1 of 2
==3488== at 0x4A07192: operator new[](unsigned long) (vg_replace_malloc.c:363)
==3487==
==3488== by 0x633AFA: LAMMPS_NS::Output::create_restart(int, char**) (output.cpp:773)
==3488== by 0x5AD3B4: LAMMPS_NS::Input::execute_command() (input.cpp:1841)
==3488== by 0x5AD876: LAMMPS_NS::Input::file() (input.cpp:243)
==3488== by 0x5BCC05: main (main.cpp:44)
(I also ran this with valgrind).
Here are the line numbers:
==3488== 95 bytes in 4 blocks are definitely lost in loss record 1 of 2
==3488== at 0x4A07192: operator new[](unsigned long) (vg_replace_malloc.c:363)
==3487==
==3488== by 0x633AFA: LAMMPS_NS::Output::create_restart(int, char**) (output.cpp:773)
==3488== by 0x5AD3B4: LAMMPS_NS::Input::execute_command() (input.cpp:1841)
==3488== by 0x5AD876: LAMMPS_NS::Input::file() (input.cpp:243)
==3488== by 0x5BCC05: main (main.cpp:44)
still having the input to reproduce it would have been very helpful.
but i figured it out from staring at the code anyway.
the bugfix is now part of pull request #248
https://github.com/lammps/lammps/pull/248/commits/5d787f7f16c9c2644585c8c8d608e03d359ff9ab
mind you, this is a rather harmless leak, as one has to issue the
restart command multiple times and for each new invocation, the
previous string for the restart name is leaked.
from the commit history it looks as if this part of the code was last
changed about 4 1/2 years ago.
axel.