Trying to copy a fairly large directory tree from a SunOS system to a Windows system using rsync 3.0.8 as the server and cwRsync 3.0.9 on the client. The client reports the following: ---------- $ ./rsync --port=8873 remotehost::module /x rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(614) [Receiver=3.0.9] ---------- The client log shows the following: ---------- 2011/10/05 11:29:32 [29628] rsyncd version 3.0.8 starting, listening on port 8873 2011/10/05 11:29:35 [29631] connect from mysystem.example.com (192.168.1.1) 2011/10/05 11:29:35 [29631] ERROR: out of memory in glob_expand_module [Receiver] 2011/10/05 11:29:35 [29631] [Receiver] _exit_cleanup(code=22, file=util.c, line=117): entered 2011/10/05 11:29:35 [29631] rsync error: error allocating core memory buffers (code 22) at util.c(117) [Receiver=3.0.8] 2011/10/05 11:29:35 [29631] [Receiver] _exit_cleanup(code=22, file=util.c, line=117): about to call exit(22) 2011/10/05 11:29:37 [29628] [Receiver] _exit_cleanup(code=20, file=rsync.c, line=549): entered 2011/10/05 11:29:38 [29628] rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(549) [Receiver=3.0.8] ---------- The rsyncd.conf file contains this: ---------- port = 8873 pid file = ./rsyncd.pid log file = ./rsyncd.log use chroot = no [module] path = /path/to/filesystem/contents ---------- The rsync daemon is running as a user process, not root (hence the need to disable chroot). I won't discount a configuration error ... this is a brand new rsync install on the system.
Might be related to the fact that the file system I was trying to sync was mounted via nfs.
I'd imagine that it is a bug with the SunOS asprintf() due to its apparent implication in bug 8090 (though I never heard back on that bug). You should check to see if that is failing, and try replacing it with the lib/snprintf.c version if it is.
The asprintf() call in question is only 1 of 2 in all of rsync that tests the success of the function via "<= 0" rather than "< 0". Perhaps just removing the '=' in those calls would fix the issue? Is the SunOS asprintf() working OK if it returns 0?
No response. Seems likely that the changes fixed this.