Bug 5309 - double free or corruption while using rsync 3.0.0 stable
double free or corruption while using rsync 3.0.0 stable
Status: CLOSED FIXED
Product: rsync
Classification: Unclassified
Component: core
3.0.1
x64 Linux
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-06 01:59 UTC by Siegfried Koloschin
Modified: 2008-07-26 10:47 UTC (History)
0 users

See Also:


Attachments
Fixed a crash bug in the backup code (1.44 KB, patch)
2008-03-15 02:48 UTC, Wayne Davison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Siegfried Koloschin 2008-03-06 01:59:51 UTC
from rsync3-pre8 to 3.0.0 stable I sometimes get the following while trying to sync two server partititions:
 rsync -pAzbrv --password-file=/etc/rsyncd.secrets --delete-after --backup-dir=/trash/zmnh/ calleo1::zmnh /zmnh/
*** glibc detected *** rsync: double free or corruption (out): 0x00000000006cf510 ***
======= Backtrace: =========
/lib64/libc.so.6[0x2b869e92ef9a]
/lib64/libc.so.6(cfree+0x8c)[0x2b869e932c1c]
rsync[0x41dc3b]
rsync[0x41e338]
rsync[0x40a4ff]
rsync[0x4112b4]
rsync[0x41880c]
rsync[0x418b84]
rsync[0x41a340]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x2b869e8ddae4]
rsync[0x403599]
======= Memory map: ========
00400000-0045b000 r-xp 00000000 08:01 3125658                            /usr/local/bin/rsync
0065b000-00660000 rw-p 0005b000 08:01 3125658                            /usr/local/bin/rsync
00660000-006f0000 rw-p 00660000 00:00 0                                  [heap]
2b869e49f000-2b869e4b9000 r-xp 00000000 08:01 1226583                    /lib64/ld-2.6.1.so
2b869e4b9000-2b869e4bb000 rw-p 2b869e4b9000 00:00 0
2b869e4bb000-2b869e4fa000 r--p 00000000 08:01 3155953                    /usr/share/locale/de_AT.UTF-8/LC_CTYPE
2b869e4fa000-2b869e501000 r--s 00000000 08:01 3123845                    /usr/lib64/gconv/gconv-modules.cache
2b869e501000-2b869e647000 rw-p 2b869e501000 00:00 0
2b869e6b8000-2b869e6b9000 r--p 00019000 08:01 1226583                    /lib64/ld-2.6.1.so
2b869e6b9000-2b869e6ba000 rw-p 0001a000 08:01 1226583                    /lib64/ld-2.6.1.so
2b869e6ba000-2b869e6c0000 r-xp 00000000 08:01 1226516                    /lib64/libacl.so.1.1.0
2b869e6c0000-2b869e8bf000 ---p 00006000 08:01 1226516                    /lib64/libacl.so.1.1.0
2b869e8bf000-2b869e8c0000 rw-p 00005000 08:01 1226516                    /lib64/libacl.so.1.1.0
2b869e8c0000-2b869ea06000 r-xp 00000000 08:01 1226408                    /lib64/libc-2.6.1.so
2b869ea06000-2b869ec05000 ---p 00146000 08:01 1226408                    /lib64/libc-2.6.1.so
2b869ec05000-2b869ec08000 r--p 00145000 08:01 1226408                    /lib64/libc-2.6.1.so
2b869ec08000-2b869ec0a000 rw-p 00148000 08:01 1226408                    /lib64/libc-2.6.1.so
2b869ec0a000-2b869ec0f000 rw-p 2b869ec0a000 00:00 0
2b869ec0f000-2b869ec13000 r-xp 00000000 08:01 1226514                    /lib64/libattr.so.1.1.0
2b869ec13000-2b869ee12000 ---p 00004000 08:01 1226514                    /lib64/libattr.so.1.1.0
2b869ee12000-2b869ee13000 rw-p 00003000 08:01 1226514                    /lib64/libattr.so.1.1.0
2b869ee13000-2b869ee15000 rw-p 2b869ee13000 00:00 0
2b869ee15000-2b869ee1f000 r-xp 00000000 08:01 1226424                    /lib64/libnss_files-2.6.1.so
2b869ee1f000-2b869f01e000 ---p 0000a000 08:01 1226424                    /lib64/libnss_files-2.6.1.so
2b869f01e000-2b869f020000 rw-p 00009000 08:01 1226424                    /lib64/libnss_files-2.6.1.so
2b869f020000-2b869f029000 r-xp 00000000 08:01 1226428                    /lib64/libnss_nis-2.6.1.so
2b869f029000-2b869f229000 ---p 00009000 08:01 1226428                    /lib64/libnss_nis-2.6.1.so
2b869f229000-2b869f22b000 rw-p 00009000 08:01 1226428                    /lib64/libnss_nis-2.6.1.so
2b869f22b000-2b869f23f000 r-xp 00000000 08:01 1226418                    /lib64/libnsl-2.6.1.so
2b869f23f000-2b869f43e000 ---p 00014000 08:01 1226418                    /lib64/libnsl-2.6.1.so
2b869f43e000-2b869f440000 rw-p 00013000 08:01 1226418                    /lib64/libnsl-2.6.1.so
2b869f440000-2b869f442000 rw-p 2b869f440000 00:00 0
2b869f442000-2b869f446000 r-xp 00000000 08:01 1226422                    /lib64/libnss_dns-2.6.1.so
2b869f446000-2b869f645000 ---p 00004000 08:01 1226422                    /lib64/libnss_dns-2.6.1.so
2b869f645000-2b869f647000 rw-p 00003000 08:01 1226422                    /lib64/libnss_dns-2.6.1.so
2b869f647000-2b869f658000 r-xp 00000000 08:01 1226434                    /lib64/libresolv-2.6.1.so
2b869f658000-2b869f857000 ---p 00011000 08:01 1226434                    /lib64/libresolv-2.6.1.so
2b869f857000-2b869f859000 rw-p 00010000 08:01 1226434                    /lib64/libresolv-2.6.1.so
2b869f859000-2b869f85b000 rw-p 2b869f859000 00:00 0
2b869f85b000-2b869f868000 r-xp 00000000 08:01 1226402                    /lib64/libgcc_s-4.2.2.so.1
2b869f868000-2b869fa67000 ---p 0000d000 08:01 1226402                    /lib64/libgcc_s-4.2.2.so.1
2b869fa67000-2b869farsync: connection unexpectedly closed (190943 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [generator=3.0.0]
I'm using Mandriva 2008-X64.
The last file rsync try's to sync is stored by macosx at a special folder with the following acls:
getfacl: Removing leading '/' from absolute path names
# file: zmnh/Inst_Po/gueven/Service/Adobe\040Acrobat\0406.0\040Professional/Acrobat\0406.0\040Professional.app/Contents/MacOS/ACECarbonLib
# owner: hmz
# group: SGedv
user::rwx
user:gueven:rwx
group::rwx
group:SG:rwx
mask::rwx
other::---
For questions, please contact me via e-mail.

Thanks
Sigi
Comment 1 Wayne Davison 2008-03-07 09:08:20 UTC
Please install an rsync binary that has debug symbols in it so that the backtrace will (I presume) display file and line-number information into rsync when the fault happens.
Comment 2 Siegfried Koloschin 2008-03-10 06:13:09 UTC
strange: if I compile rsync with "enable maintainer mode" and run the rsync
-client as root from bash, after the crash it tells me "xterm ...: Can´t open display" for some more debug output. Why do I need a XTerm for the output?
if I run the client as non root, it tells me that -A is an unknown option....
Anyway, this is how you can reproduce the crash (hopefully):
At the source server at an xfs-partition create a folder with a default acl. The folder should contain some files.
At the destination server sync this folder with my options (rsync -pAzbrv). Make sure the folder with ACLs does not exist in the trash. 
To be sure rsync tries to create the folder in the trash directory, don´t use -u.
You should notice that rsync creates the folder with ACLs in the trash dir, but not the files in the folder. At that moment the crash happens.

regards
Sigi
Comment 3 Wayne Davison 2008-03-15 02:47:04 UTC
Thanks for providing the details of how to reproduce the problem.  I've checked-in a fix.  I'll also attach a patch to this report.
Comment 4 Wayne Davison 2008-03-15 02:48:43 UTC
Created attachment 3174 [details]
Fixed a crash bug in the backup code

This patch allocate room for a dir's default ACL so that memory doesn't get corrupted.