Bug 12173 - memory leak around poptGetOptArg()
memory leak around poptGetOptArg()
Status: NEW
Product: rsync
Classification: Unclassified
Component: core
3.1.1
All All
: P5 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-08-24 13:34 UTC by T Yamada
Modified: 2017-06-21 09:21 UTC (History)
0 users

See Also:


Attachments

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== 
==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