Bug 8508 - out of memory in glob_expand_module
out of memory in glob_expand_module
Product: rsync
Classification: Unclassified
Component: core
All Solaris
: P5 minor
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2011-10-05 16:26 UTC by David G
Modified: 2013-02-18 13:31 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description David G 2011-10-05 16:26:49 UTC
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 (
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

        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.
Comment 1 David G 2011-10-05 19:13:04 UTC
Might be related to the fact that the file system I was trying to sync was mounted via nfs.
Comment 2 Wayne Davison 2011-10-06 06:10:36 UTC
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.
Comment 3 Wayne Davison 2011-10-06 15:55:44 UTC
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?
Comment 4 Wayne Davison 2011-12-24 20:11:12 UTC
No response.  Seems likely that the changes fixed this.