search for: flist_expand

I am running rsync version 2.5.5 on Tru64 UNIX on two AlphaServers running version 4.0F and version 5.1. Rsync fails with the error message: ERROR: out of memory in flist_expand A log of the command I am using is: # rsync --dry-run --recursive --delete foo:/foo1 /bar1/foo1copy receiving file list ... done ERROR: out of memory in flist_expand rsync error: error allocating core memory buffers (code 22) at util.c(232) # echo $status 22 # Any advice will be much appreciated...

Hello list, I get the following error using rsync 3.0.3 (both sides): ... data/xxxxxxxx/admin_docs/2/8/9/9/0/7/9/msg-75682-748.msg is uptodate data/xxxxxxxx/admin_docs/2/8/9/9/0/8/0/msg-75682-749.txt is uptodate ERROR: out of memory in flist_expand [generator] rsync error: error allocating core memory buffers (code 22) at util.c(117) [generator=3.0.3] rsync error: received SIGUSR1 (code 19) at main.c(1286) [receiver=3.0.3] Command was: rsync -avvz remotehost:/var/www /backup These things I have tried to fix the problem: After starting...

...ist pointer array to 671088640 bytes, did not move [generator] expand file_list pointer array to 805306368 bytes, did not move [generator] expand file_list pointer array to 939524096 bytes, did not move [generator] expand file_list pointer array to 1073741824 bytes, did move ERROR: out of memory in flist_expand [generator] usr/bin/ rsync: [sender] write error: Broken pipe (32) rsync error: error in socket IO (code 10) at io.c(823) [sender=3.1.0dev] Using the official 3.0.8 (ie not Ubuntu's), I get similar buffer sizes, and a slightly more informative error message: error allocating core memory buffe...

Hi, I have just downloaded the SunOS version of rsync from ftp://rsync.samba.org/pub/rsync/binaries/Sunos/ When I run it on my machines I get the following error message ./rsync -xr /usr /mnt ERROR: out of memory in flist_expand rsync error: error allocating core memory buffers (code 22) at util.c(232) There is free memory on the system. Thankis, joe. -------------- next part -------------- A non-text attachment was scrubbed... Name: joe.manning.vcf Type: text/x-vcard Size: 341 bytes Desc: Card for Joe Manning Url : http...

...r and resulted in the wrong data being copied. * Fixed compilation errors on some systems caused by the use of "unsigned int64" in rsync.h. * Fixed problem on systems such as Sunos4 that do not support realloc on a NULL pointer; error was "out of memory in flist_expand". * Fix for rsync server processes hanging around after the client unexpectedly disconnects. (Colin Walters) (Debian bug #128632) * Cope with BSD systems on which mkdir() will not accept a trailing slash. ENHANCEMENTS: * Command to initiate connections is only sh...

Hello again, I encountered something amazing. First I thought there is not enough memory allowed through ulimit. ulimit is now set to (almost) 512MB but rsync still gets out fo memory at 8MB. Can anyone tell me why? That's my configuration: rsync version 2.6.2 from AIX 5.3 to SuSE Linux 9 (also has rsync 2.6.2) ulimit -a (AIX) ulimit -a AIX (source): -------------------------

...le list build and about 1.5GB is used during the actual >> transfer. The client has 16GB of RAM with a peak usage of 8.5GB. > >> I just tried three transfers in a row and it consistently breaks >> at a certain point, after which I get the "ERROR: out of memory >> in flist_expand [sender]" error. There is not much special to >> mention regarding the file on which it breaks: it's a 22KB JPEG >> file with no special attributes. > >> The backup server is running Debian 7.8, the client runs on >> CentOS 5.11. > >> A `find . | wc -l...

...4 01:47:41 -0000 1.174 +++ flist.c 27 Jan 2004 07:36:30 -0000 @@ -46,6 +46,7 @@ extern int recurse; extern char curr_dir[MAXPATHLEN]; extern char *files_from; extern int filesfrom_fd; +extern char *who_am_i; extern int one_file_system; extern int make_backups; @@ -342,7 +343,8 @@ static void flist_expand(struct file_lis } if (verbose >= 2) { - rprintf(FINFO, "expand file_list to %.0f bytes, did%s move\n", + rprintf(FINFO, "[%c] expand file_list to %.0f bytes, did%s move\n", + *who_am_i, (double)sizeof(flist->files[0]) * flist->malloced, (ne...

...is used during the actual >>> transfer. The client has 16GB of RAM with a peak usage of >>> 8.5GB. > >>> I just tried three transfers in a row and it consistently >>> breaks at a certain point, after which I get the "ERROR: out of >>> memory in flist_expand [sender]" error. There is not much >>> special to mention regarding the file on which it breaks: it's >>> a 22KB JPEG file with no special attributes. > >>> The backup server is running Debian 7.8, the client runs on >>> CentOS 5.11. > >>&...

...ums, 32-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, no IPv6, batchfiles, inplace, append, ACLs, no xattrs, iconv, no symtimes, no prealloc I'm hoping that by using 64-bit inums, I will be able to avoid this error that I'm getting: ERROR: out of memory in flist_expand [sender] rsync error: error allocating core memory buffers (code 22) at util2.c(106) [sender=3.1.2] rsync: [sender] write error: Broken pipe (32) I've gotten around this by sub-dividing the rsync into smaller chunks but would like to avoid this if possible. Thanks in advance, Tom -- Tom C...

Hi, I am experiencing segfaults when transferring files via rsync though sudo. Setup: - Backupserver initiates the rsync command with --delete -vvv --no-inc-recursive --numeric-ids --delete-excluded --relative --rsync-path=/home/backupuser/rsync-wrapper.sh - rsync-wrapper.sh (on the client) contains /usr/bin/sudo /usr/bin/rsync "$@"; - user "backupuser" has sudo access to the

...1.5GB is used during the actual > >> transfer. The client has 16GB of RAM with a peak usage of 8.5GB. > > > >> I just tried three transfers in a row and it consistently breaks > >> at a certain point, after which I get the "ERROR: out of memory > >> in flist_expand [sender]" error. There is not much special to > >> mention regarding the file on which it breaks: it's a 22KB JPEG > >> file with no special attributes. > > > >> The backup server is running Debian 7.8, the client runs on > >> CentOS 5.11. > &gt...

i've built up rsync on both opensuse & osx from src. on osx, it's v2.6.3 w/ both apple's "Extended Attributes" patches: http://www.opensource.apple.com/darwinsource/10.4.8.ppc/rsync-24/patches/EA.diff http://www.opensource.apple.com/darwinsource/10.4.8.ppc/rsync-24/patches/PR-3945747-endian.diff and the 'lartmaker' fix (iteself, slightly fixed ...):

...of which about 3GB is used during the file list build and about 1.5GB is used during the actual transfer. The client has 16GB of RAM with a peak usage of 8.5GB. I just tried three transfers in a row and it consistently breaks at a certain point, after which I get the "ERROR: out of memory in flist_expand [sender]" error. There is not much special to mention regarding the file on which it breaks: it's a 22KB JPEG file with no special attributes. The backup server is running Debian 7.8, the client runs on CentOS 5.11. A `find . | wc -l` in the backup directory results in 7434013 files. --...

...t; >>> transfer. The client has 16GB of RAM with a peak usage of > >>> 8.5GB. > > > >>> I just tried three transfers in a row and it consistently > >>> breaks at a certain point, after which I get the "ERROR: out of > >>> memory in flist_expand [sender]" error. There is not much > >>> special to mention regarding the file on which it breaks: it's > >>> a 22KB JPEG file with no special attributes. > > > >>> The backup server is running Debian 7.8, the client runs on > >>> CentO...

...build and about 1.5GB is used during the actual transfer. The > > client has 16GB of RAM with a peak usage of 8.5GB. > > > > I just tried three transfers in a row and it consistently breaks at > > a certain point, after which I get the "ERROR: out of memory in > > flist_expand [sender]" error. There is not much special to mention > > regarding the file on which it breaks: it's a 22KB JPEG file with > > no special attributes. > > > > The backup server is running Debian 7.8, the client runs on CentOS > > 5.11. > > > > A `f...

...ndex: flist.c =================================================================== RCS file: /cvsroot/rsync/flist.c,v retrieving revision 1.230 diff -c -b -d -r1.230 flist.c *** a/flist.c 11 Jun 2004 07:40:57 -0000 1.230 --- b/flist.c 17 Jun 2004 04:01:55 -0000 *************** *** 950,956 **** flist_expand(flist); ! if (write_batch) file->flags |= FLAG_TOP_DIR; if (file->basename[0]) { --- 950,956 ---- flist_expand(flist); ! if (write_batch) /* uh, why? TODO: remove and test */ file->flags |= FLAG_TOP_DIR; if (file->basename[0]) { *************** *** 10...

...sfer. The client has 16GB of RAM with a peak usage of >> >>> 8.5GB. >> > >> >>> I just tried three transfers in a row and it consistently >> >>> breaks at a certain point, after which I get the "ERROR: out of >> >>> memory in flist_expand [sender]" error. There is not much >> >>> special to mention regarding the file on which it breaks: it's >> >>> a 22KB JPEG file with no special attributes. >> > >> >>> The backup server is running Debian 7.8, the client runs on >&gt...

...} Index: flist.c =================================================================== RCS file: /cvsroot/rsync/flist.c,v retrieving revision 1.231 diff -c -b -d -r1.231 flist.c *** flist.c 18 Jun 2004 16:29:21 -0000 1.231 --- flist.c 12 Jul 2004 00:37:47 -0000 *************** *** 950,958 **** flist_expand(flist); - if (write_batch) - file->flags |= FLAG_TOP_DIR; - if (file->basename[0]) { flist->files[flist->count++] = file; send_file_entry(file, f, base_flags); --- 950,955 ---- *************** *** 1301,1313 **** * protocol version 15 */ recv_uid_list(f, flist)...

As those of you who watch CVS will be aware Wayne has been making progress in reducing memory requirements of rsync. Much of what he has done has been the product of discussions between he and myself that started a month ago with John Van Essen. Most recently Wayne has changed how the file_struct and its associated data are allocated, eliminating the string areas. Most of these changes have been