Mail Archives: cygwin/2006/01/07/20:55:00
<...snip...>
> Does this tell anyone anything? If not, I could traverse the learning
> curve on getting gdb information from the process.
As a point of information, when rsync is run, as in this case using ssh,
it is using ssh to start a remote rsync on the server. These two rsyncs
are able to communicate with each other because the standard in (stdin)
of each is connected to the standard out (stdout) of the other over the
network. So althought there is buffering, each must read and write at
the appropriate times in a well understood sequence/protocol as other
wise they come out of sync and fail, most likely in a deadlock.
On the surface is *looks* like the problem is that the local rsync is
hanging on a write to stdout (descriptor 1 in your trace). The
question is why. It is not clear to me if it has simply failed to fully
read all that the remote rsync needs to send and therefore there is in
a deadly embrace or the remote has exited and the socket wasn't
properly cleaned up.
As far as using gdb, rather than using the full rsync command line, use
the command 'gdb rsync' to start rsync in the debugger. Then enter the
command 'run balance-of-rsync-command-line' and it should run normally.
Once it hangs, use control-c to break to the gdb command prompt and use
the command 'where' or 'bt' (back trace) to print a stack trace.
It would be very interested to log into the server and use ps to
locate the remote rsync during the run. I don't know of this is an
option for you. If so, you could see if the remote rsync has exited.
If not, you could attach to it using gdb and perform a stack trace,
presuming you could compile it with debug. Kinda of a pain as you'd
have to either move it to /usr/bin or you could explicitly reference
the alternate copy in your Cygwin built rsync. That is the local
rsync will build a command line to run rsync on the server via ssh
that depends on the path, but you could hard-code a path to your
debuggable rsync on the server.
Not sure how far you want to push this, I think this is going to take
some digging.
Brett
----------------------------------------------------------------
Brett C. Serkez, Techie
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -