On 29 Aug 2002, "Hien D. Ngo" <hien at moses.xp.com> wrote:
>> As luck would have it, two compile sessions got hung up. The backtrace info for the
> other side is not very useful, though.
>> I'll try the HAVE_SENDFILE recompile and report back.
It looks like this one is the other way around. I think on your first
mail it was transmission of the .o file from server to client that
hung, whereas here it is the transmission of the .i file from client
to server.
Thanks for reproducing it.
In the original bug report, there was data in the sender's transmit
queue and nothing in the receiver's receive queue. That's pretty
strange -- it almost looks as if there is a kernel bug that is
stopping it from being pushed across. It would help if you could
include the output of "netstat -to" to show what the kernel thinks its
doing, and also perhaps a tcpdump on that socket for one minute or so
after you notice it's got into the stuck state. For example, if the
client is on port 54522, do "tcpdump tcp port 54522". I noticed that
in the
Perhaps the strange stack shown by gdb indicates that
The other thing that might help describe it, since gdb isn't
cooperating, is an strace of the two processes leading up to the
hang. Do something like "strace -o /tmp/distccd.trace -ff `pidof
distccd`".
Thanks,
--
Martin