On Fri, Apr 14, 2017 at 08:22:29PM +0300, Boris Savelev via rsync wrote:
> I use rsync from python on my Debian Jessie amd64 and get this error:
> *** buffer overflow detected ***: <snip>/rsync terminated
> I rebuild rsync-3.1.1 from Debian source with debug and -O1 and get bt from
> (gdb) bt
> #5 0x00007ffff791ca17 in __fdelt_chk (d=d@entry=1606) at fdelt_chk.c:25
> #6 0x0000555555584c78 in safe_read (fd=fd@entry=1606,
> buf=buf@entry=0x7fffffffa810 "\037", len=len@entry=4) at io.c:245
That is FD_SET(fd, &r_fds); with fd >= FD_SETSIZE, which is 1024.
You cannot use select with file descriptor numbers >= FD_SETSIZE (or < 0),
and glibc is catching that.
The "buffer" that would overflow is the fd_set.
Maybe rsync could simply close all inherited file descriptors,
first things first, before it does anything else,
possibly after making sure fds 0,1,2 are open to somewhere,
to avoid any output to "supposedly" stdout/stderr to clobber
fds opened only later. Similar to what lvm tools do in their
_check_standard_fds() and _close_stray_fds()?
But of course rsync could also say: not my problem, *you* (whatever
entity was spawning rsync) leaked file descriptors, learn to use
O_CLOEXEC resp. set FD_CLOEXEC, so only 0,1,2 will be inherited.
quick and dirty workaround:
use a wrapper script, close all fds >= 3 "just in case",
then exec rsync.
> It looks like a bug, but I'm not sure)
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html