Mail Archives: cygwin/2009/08/13/15:52:36
cygwin <karl <at> sipxx.com> writes:
>
> - if (dup2(to_child_pipe[0], STDIN_FILENO) < 0 ||
> - close(to_child_pipe[1]) < 0 ||
> - close(from_child_pipe[0]) < 0 ||
> - dup2(from_child_pipe[1], STDOUT_FILENO) < 0) {
> - rsyserr(FERROR, errno, "Failed to dup/close");
> + if (dup2(to_child_pipe[0], STDIN_FILENO) < 0) {
> + rsyserr(FERROR, errno, "Failed to dup2(to-0)");
> exit_cleanup(RERR_IPC);
> }
> - if (to_child_pipe[0] != STDIN_FILENO)
> - close(to_child_pipe[0]);
> - if (from_child_pipe[1] != STDOUT_FILENO)
> - close(from_child_pipe[1]);
Ouch. rsync has a bug even without your patch: if you run rsync with stdout
closed (as opposed to redirected), then to_child_pipe[0] can be 1, and you end
up closing the just-duplicated from_child_pipe[1] that was copied to the new
stdout. To be correct, rsync must compare to_child_pipe[0] against both 0 and
1, not just 0 (likewise for from_child_pipe[1] against both 0 and 1, not just
1). Amazing how often this type of bug reappears, too - historical cygwin has
had it in the past with newlib's popen implementation (I fixed it 2006-08-22),
as well as m4 1.4.13-1 having it due to code from gnulib (I fixed it 2009-07-
17).
As an aside, it's interesting to note that on mingw, dup2(1,1) succeeds, but
has the result of corrupting the fd, such that if you later do dup2(1,2), it
hangs. But the fact that mishandled attempts to duplicate Windows handles can
lead to weird bugs sure lends credence to the idea that BLODA may be making the
matter worse when we duplicate an open socket handle.
--
Eric Blake
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -