Running rsync 2.6.9 on Fedora Core 6, 32-bit x86 architecture, I get frequent aborts due to a free() error detected by glibc. Error message is appended. The error is reproducible if I run with the exact same set of arguments, but if the file list to be transferred changes, it may work correctly. Running with $MALLOC_CHECK_=1 works around the problem. As far as I can tell, the errors come from the receiving rsync, not the sending one. Richard Brittain *** glibc detected *** rsync: double free or corruption (fasttop): 0x08b30d68 *** ======= Backtrace: ========= /lib/libc.so.6[0xa6fa96] /lib/libc.so.6(cfree+0x90)[0xa72fb0] rsync[0x804b721] rsync[0x804b9bb] rsync[0x804f3dd] rsync[0x80588f5] rsync[0x80590e0] rsync[0x805998e] /lib/libc.so.6(__libc_start_main+0xdc)[0xa1edec] rsync[0x804a811] ======= Memory map: ======== 00691000-00697000 r-xp 00000000 fd:00 17006780 /lib/libacl.so.1.1.0 00697000-00698000 rwxp 00005000 fd:00 17006780 /lib/libacl.so.1.1.0 00871000-00875000 r-xp 00000000 fd:00 17006647 /lib/libattr.so.1.1.0 00875000-00876000 rwxp 00003000 fd:00 17006647 /lib/libattr.so.1.1.0 009ec000-00a05000 r-xp 00000000 fd:00 17006631 /lib/ld-2.5.so 00a05000-00a06000 r-xp 00019000 fd:00 17006631 /lib/ld-2.5.so 00a06000-00a07000 rwxp 0001a000 fd:00 17006631 /lib/ld-2.5.so 00a09000-00b43000 r-xp 00000000 fd:00 17006683 /lib/libc-2.5.so 00b43000-00b45000 r-xp 0013a000 fd:00 17006683 /lib/libc-2.5.so 00b45000-00b46000 rwxp 0013c000 fd:00 17006683 /lib/libc-2.5.so 00b46000-00b49000 rwxp 00b46000 00:00 0 00b8f000-00b90000 r-xp 00b8f000 00:00 0 [vdso] 00f8e000-00f97000 r-xp 00000000 fd:00 17006632 /lib/libnss_files-2.5.so 00f97000-00f98000 r-xp 00008000 fd:00 17006632 /lib/libnss_files-2.5.so 00f98000-00f99000 rwxp 00009000 fd:00 17006632 /lib/libnss_files-2.5.so 0565b000-05662000 r-xp 00000000 fd:00 5834125 /usr/lib/libpopt.so.0.0.0 05662000-05663000 rwxp 00006000 fd:00 5834125 /usr/lib/libpopt.so.0.0.0 05725000-05730000 r-xp 00000000 fd:00 17006682 /lib/libgcc_s-4.1.2-20070626.so.1 05730000-05731000 rwxp 0000a000 fd:00 17006682 /lib/libgcc_s-4.1.2-20070626.so.1 08047000-08093000 r-xp 00000000 fd:00 5845875 /usr/bin/rsync 08093000-08095000 rw-p 0004c000 fd:00 5845875 /usr/bin/rsync 08095000-080a5000 rw-p 08095000 00:00 0 08b2b000-08b92000 rw-p 08b2b000 00:00 0 b7c00000-b7c21000 rw-p b7c00000 00:00 0 b7c21000-b7d00000 ---p b7c21000 00:00 0 b7d22000-b7d63000 rw-p b7d22000 00:00 0 b7d63000-b7f63000 r--p 00000000 fd:00 5859512 /usr/lib/locale/locale-archive b7f63000-b7f65000 rw-p b7f63000 00:00 0 bfd01000-bfd17000 rw-p bfd01000 00:00 0 [stack] rsync: connection unexpectedly closed (8 bytes received so far) [sender] rsync error: unexplained error (code 255) at io.c(453) [sender=2.6.9]
Well, could you show us the crashing command line and the file list (unless it's secret)? Could you reproduce the problem in a copy of rsync 2.6.9 that has debug info in order to get a backtrace containing function names?
Created attachment 2877 [details] Example file list which exhibits the problem Removing either /etc/mail or /usr/lib/httpd/modules from the list makes the error go away. The actual command line is (part of a script, with obvious substitutions) rsync --files-from system-sync-list --delete -avr --rsync-path=/usr/local/etc/rsync-debug -F / $targetuser@$targethost:/
Created attachment 2878 [details] strace output from receiving rsync process
This appears to be the same crash as bug 4855, caused by the combination of -R (implied by --files-from) and -F and some uninitialized memory in the filter handling. That bug report has a quick fix for 2.6.9, and development version has this fixed.