Bug 739794 - memory leak around free_xattr() and rsync_xal_free(), 200 bytes per file and per directory
Summary: memory leak around free_xattr() and rsync_xal_free(), 200 bytes per file and ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: rsync
Version: 14
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Luscon
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-20 03:52 UTC by Tim Taiwanese Liim
Modified: 2012-11-07 09:25 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-16 14:46:48 UTC


Attachments (Terms of Use)

Description Tim Taiwanese Liim 2011-09-20 03:52:31 UTC
Description of problem:
    With flag "-aX", rsync creates xattr data structure, but does not free
    it when done.  This leads to 200 bytes of memory leak for each file
    and each dir, or a few giga for my big backup job.

    In free_xattr(), we have
        rsync_xal_free(sxp->xattr);
        free(sxp->xattr);
        sxp->xattr = NULL;
    In rsync_xal_free() we should also free the pointer to allocated memory:
        rsync_xa *rxas = xalp->items;  // "xalp" is "sxp->xattr"
        free(rxas);            <== need to add this line
        xalp->items = NULL;    <== for good practice.
        xalp->count = 0;
    because xalp->items comes from malloc() earlier in expand_item_list():
        new_ptr = _realloc_array(...); // wrapper of malloc() and realloc()
        lp->items = new_ptr;

Version-Release number of selected component (if applicable):
    rsync-3.0.8-1.fc14.x86_64

How reproducible:
    always, with "-aX" flag.

Steps to Reproduce:
1. create a few source files
    d1=/tmp/t1
    d2=/tmp/t2
    mkdir $d1
    cd    $d1
    for i in {1..40}; do mkdir -p $i; echo 123 > $i/a$i; cp $i/a$i $i/b$i; done

2. use valgrind to check for memory leak
    rm -rf $d2; 
    valgrind --leak-check=full rsync -aX $d1/ $d2/

Actual results:
    valgrind indicates memory leak.

Expected results:
    no memory leak, at least no big ones.

Additional info:
  - valgrind reports 200 bytes leak for each file processed:

    16,000 bytes in 80 blocks are definitely lost in loss record 25 of 28
       at 0x4A05E46: malloc (vg_replace_malloc.c:195)
       by 0x41E1D6: _realloc_array (util.c:1438)
       by 0x41EE44: expand_item_list (util.c:1697)
       by 0x43CF1E: rsync_xal_get (xattrs.c:271)
       by 0x43D165: get_xattr (xattrs.c:315)
       by 0x4077A7: send_file_name (flist.c:1437)
       by 0x40826C: send_directory (flist.c:1678)
       by 0x408A80: send1extra (flist.c:1832)
       by 0x408E12: send_extra_file_list (flist.c:1904)
       by 0x417491: send_files (sender.c:184)
       by 0x421262: client_run (main.c:1039)
       by 0x421CF3: start_client (main.c:1287)


  - There is another unrelated leak at much lower rate; 
    109 bytes in 39 blocks are definitely lost in loss record 17 of 30
       at 0x4A05E46: malloc (vg_replace_malloc.c:195)
       by 0x41E05E: _new_array (util.c:1429)
       by 0x405305: recv_file_entry (flist.c:709)
       by 0x40A442: recv_file_list (flist.c:2362)
       by 0x42C9DD: read_msg_fd (io.c:376)
       by 0x42D269: wait_for_receiver (io.c:540)
       by 0x41434D: generate_files (generator.c:2345)
       by 0x420B63: do_recv (main.c:843)
       by 0x420F5C: do_server_recv (main.c:953)
       by 0x421057: start_server (main.c:983)
       by 0x420F9D: child_main (main.c:960)
       by 0x440167: local_child (pipe.c:156)
   Just FYI; not sure if you want to fix it.

Comment 1 Tim Taiwanese Liim 2011-09-22 02:01:42 UTC
Opened upstream bug
    https://bugzilla.samba.org/show_bug.cgi?id=8475
    memory leak around free_xattr() and rsync_xal_free(), with -aX,
    200 bytes per file and per directory

Comment 2 Fedora End Of Life 2012-08-16 14:46:51 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


Note You need to log in before you can comment on or make changes to this bug.