The Samba-Bugzilla – Bug 12173
memory leak around poptGetOptArg()
Last modified: 2017-06-27 09:18:12 UTC
Description of problem:
In poptGetOptArg(), con->os->nextArg is set to be NULL, which means the returned memory is out of popt management.
We have to free it.
Version-Release number of selected component (if applicable):
(perhaps the latest version is also affected, according to the source code)
always, with "--chmod=u+x" flag
Steps to Reproduce:
valgrind --tool=memcheck rsync --chmod=u+x
valgrind indicates memory leak.
no memory leak, at least no big ones.
Carefully read, it looks like POPT_ARG_STRING values also have to be freed (such as shell_cmd and logfile_name).
But since they are global variables, they are represented as "still reachable".
Further investigation is required for this side.
3.1.1 is still affected. How is it going?
==22846== 4 bytes in 1 blocks are definitely lost in loss record 2 of 8
==22846== at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22846== by 0x524049E: ??? (in /lib/x86_64-linux-gnu/libpopt.so.0.0.0)
==22846== by 0x5241994: poptGetNextOpt (in /lib/x86_64-linux-gnu/libpopt.so.0.0.0)
==22846== by 0x13AE04: ??? (in /usr/bin/rsync)
==22846== by 0x114D7E: main (in /usr/bin/rsync)
==22846== LEAK SUMMARY:
==22846== definitely lost: 4 bytes in 1 blocks
==22846== indirectly lost: 0 bytes in 0 blocks
==22846== possibly lost: 0 bytes in 0 blocks
==22846== still reachable: 890 bytes in 7 blocks
==22846== suppressed: 0 bytes in 0 blocks
I think there are more urgent problems than a memory leak of less than 1kB, which I expect isn't really a leak but memory which isn't freed at the end of execution but may be used up to that time. So is it really a leak or a bit of bad housekeeping which doesn't matter at all?
> definitely lost: 4 bytes in 1 blocks
For entire program.
But maybe this priority is low.