Bug 3202 - rsync crash with long directory structure
rsync crash with long directory structure
Product: rsync
Classification: Unclassified
Component: core
All Linux
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2005-10-22 12:48 UTC by pavel stano
Modified: 2006-03-12 02:56 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description pavel stano 2005-10-22 12:48:22 UTC
use filesystem was XFS
how to reproduce:
# while true; do mkdir a; cd a; mkdir b;cd b; done
# find ./a |tail -1
./a/b/a/b/a/b/a/b/a/b/a/b (very long)
# find ./a |tail -1|wc -c
# rsync -r /a/ /b/
rsync: writefd_unbuffered failed to write 85 bytes: phase "unknown" [receiver]:
Broken pipe (32)
rsync error: error in rsync protocol data stream (code 12) at io.c(1099)
zsh: segmentation fault  rsync -r /a/ /b/
Comment 1 pavel stano 2005-10-22 16:02:19 UTC
i find out that it crash because it fill up stack
which is default 8MB, when i enlarge it to 32mb with ulimit, rsync work ok
Comment 2 Wayne Davison 2005-11-01 10:19:05 UTC
Your diagnostic work is helpful:  rsync calls a recursive function for every
level downward in the directory hierarchy, so you need enough stack to be able
to descend low enough to the deepest subdir.  The one thing that makes the stack
memory use so large is that rsync is currently allocating a filename buffer on
the stack for every level of directory descent.  I'll check to see if this would
be easy to optimize that.
Comment 3 Wayne Davison 2005-11-01 13:17:53 UTC
The latest CVS source (also available in the latest "nightly" tar file) now uses
a lot less memory for each level of directory recursion -- I eliminated the need
for the MAXPATHLEN buffer, and replaced it with 3 small variables (typically 12
bytes or so).