Bug 6293 - rsync crashes when transferring files
rsync crashes when transferring files
Status: RESOLVED FIXED
Product: rsync
Classification: Unclassified
Component: core
3.1.0
x86 Mac OS X
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-26 10:43 UTC by Dirk Tilger
Modified: 2010-08-22 04:23 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Tilger 2009-04-26 10:43:07 UTC
I'm using rsync to backup a virtual machine that has no direct USB support. rsync fails with the following messages:

-----8<-----
rsync -az --recursive --append --delete --delete-excluded --progress --exclude .Trash --exclude file1.extension --exclude directory1 host1.local:/home/dirk/ /Volumes/volume1/Backup/host1.local/home/dirk
receiving file list ... 
rsync: opendir "/home/dirk/application1-tools-linuxjiVQAZ" failed: Permission denied (13)
rsync: opendir "/home/dirk/.dbus" failed: Permission denied (13)
50918 files to consider
IO error encountered -- skipping file deletion
rsync: send_files failed to open "/home/dirk/.viminfo": Permission denied (13)
rsync: open "/Volumes/volume1/Backup/host1.local/home/dirk/src/application2-0.3/.svn/text-base/build.xml.svn-base" failed: Permission denied (13)
rsync: connection unexpectedly closed (1256948 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [generator=3.0.5]
-----8<-----

After the last message I receive an alert from the MacOSX crash reporter about a access violation. I made the kernel dump it core and got the following backtrace:

-----8<-----
#0  0x0003123b in map_ptr (map=0x0, offset=0, len=32768) at fileio.c:192
192             if (offset >= map->p_offset && offset+len <= map->p_offset+map->p_len)
(gdb) bt
#0  0x0003123b in map_ptr (map=0x0, offset=0, len=32768) at fileio.c:192
#1  0x00011e54 in receive_data (f_in=5, fname_r=0x0, fd_r=-1, size_r=0, fname=0x0, fd=-1, total_size=50263) at receiver.c:202
#2  0x00012271 in discard_receive_data (f_in=<value temporarily unavailable, due to optimizations>, length=<value temporarily unavailable, due to optimizations>) at receiver.c:321
#3  0x000133f2 in recv_files (f_in=5, local_name=0x0) at receiver.c:695
#4  0x0001cd9c in do_recv (f_in=5, f_out=4, local_name=0x0) at main.c:774
#5  0x0001d187 in client_run (f_in=5, f_out=4, pid=9689, argc=1, argv=0x300354) at main.c:1068
#6  0x0001e290 in main (argc=2, argv=0x300350) at main.c:1275
-----8<-----

I have no clue what's happening inside my virtual machine.

On the the end with the crash, this is what I believe happens:
 - something causes line 689 in receiver.c to return -1
 - discard_receive_data gets called
 - receive_data gets called with fd_r=-1
 - line 181 of receiver.c doesn't match
 - line 189 sets mapbuf = NULL
 - line 202 calls map_ptr with map=0x0
 - line 192 tries to access map->p_offset with a NULL pointer

I have a core dump and can provide more information if required.
Comment 1 roland 2009-08-07 04:52:35 UTC
can you (reproducably) track that down to a specific file/directory which makes this happen ?
Comment 2 Dirk Tilger 2010-01-15 11:56:49 UTC
(In reply to comment #1)
> can you (reproducably) track that down to a specific file/directory which makes
> this happen ? 

Sorry for not replying for so long. I'm not sure whether I understand your question. I believe handling of fd_r=-1 and its effects should be done differently in receiver.c and/or fileio.c (which should expect to be given a NULL pointer in map).
Comment 3 Wayne Davison 2010-08-21 16:28:37 UTC
I'm committing a fix that avoids the map_ptr() calls when receive_data() is called with fd_r < 0.
Comment 4 Dirk Tilger 2010-08-22 04:23:36 UTC
(In reply to comment #3)
> I'm committing a fix that avoids the map_ptr() calls when receive_data() is
> called with fd_r < 0.

Awesome! Cheers and thanx for the effort. :)

Dirk.