Albert Chin reports:
I'm getting a SEGV on a FreeBSD 4.8-STABLE box. The client is Solaris
9/SPARC. Both boxes run 2.6.2.
The command I'm running is:
$ rsync -arHRv --numeric-ids --delete --exclude=/opt/dist/cdrom \
If I whittle down what appears in [paths], then it works.
$ gdb rsync rsync.core
#0 0x280faf0d in strncmp () from /usr/lib/libc.so.4
#1 0x7 in ?? ()
#2 0x80597f7 in send_file_name (f=-1, flist=0x808a100,
fname=0xbfbfe994 "etc/opt/TWWfsw", recursive=1, base_flags=1)
#3 0x805a2fc in send_file_list (f=-1, argc=0, argv=0xbfbffa44) at flist.c:1178
#4 0x804c0ff in delete_files (flist=0x808a0c0) at receiver.c:102
#5 0x805177e in do_recv (f_in=0, f_out=1, flist=0x808a0c0, local_name=0x0)
#6 0x8051bae in do_server_recv (f_in=0, f_out=1, argc=1, argv=0x808a064)
#7 0x8051ca9 in start_server (f_in=0, f_out=1, argc=2, argv=0x808a060)
#8 0x8052a89 in main (argc=2, argv=0x808a060) at main.c:1041
Based on #2, seems the SEGV is in make_file but #1 doesn't show the
function name and line number. Odd.
Created attachment 532 [details]
Fixed the crash bug in make_file().
When the --delete option iterates over all the specified [paths] it clears the
delete-file_list after each one. This makes the "lastdir" pointer no longer
valid. The appended patch fixes this bug and also a similar bug that could
affect the batch code.
The attached fix is in CVS, and will appear in the next version of rsync.
*** Bug 1448 has been marked as a duplicate of this bug. ***