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): rsync 3.0.6 (perhaps the latest version is also affected, according to the source code) How reproducible: always, with "--chmod=u+x" flag Steps to Reproduce: valgrind --tool=memcheck rsync --chmod=u+x Actual results: valgrind indicates memory leak. Expected results: no memory leak, at least no big ones. Additional info: 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== ==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.
Yeah, we don't worry about the small amount of memory used in the option parsing since it doesn't occur multiple times in a run.