Bug 12173 - memory leak around poptGetOptArg()
Summary: memory leak around poptGetOptArg()
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.1
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2016-08-24 13:34 UTC by T Yamada
Modified: 2020-07-26 09:36 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description T Yamada 2016-08-24 13:34:48 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):
    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.
Comment 1 T Yamada 2017-06-21 09:21:58 UTC
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
Comment 2 Paul Slootman 2017-06-27 09:07:10 UTC
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?
Comment 3 T Yamada 2017-06-27 09:18:12 UTC
> definitely lost: 4 bytes in 1 blocks
For entire program.
But maybe this priority is low.
Comment 4 Wayne Davison 2020-07-26 09:36:32 UTC
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.