[distcc] sendfile.c out of date comment. Bug in linux-2.6.12's 32
bit sendfile on x86_64.
Daniel Kegel
dank at kegel.com
Fri Nov 4 22:16:09 GMT 2005
Looks like the comment in src/sendfile.c
* Our sockets are never non-blocking, so that seems to me to say that
* the kernel will never return EAGAIN -- we will always either send
* the whole thing or get an error. Is that really true?
needs updating, since the socket was set to nonblocking in dcc_connect_by_addr().
- Dan
p.s. We noticed this while tracking down the following problem:
On an x86_64 system running a 64 bit 2.6.12 kernel and a 32
bit version of distcc, things weren't working at all.
We used strace and tcpdump to observe distcc sending a 35198 byte file:
3037 sendfile(5, 3, [0], 35198) = 11041
3037 sendfile(5, 3, [0], 24157) = -1 EAGAIN (Resource temporarily unavailable)
3037 sendfile(5, 3, [0], 24157) = 10136
3037 sendfile(5, 3, [0], 14021) = -1 EAGAIN (Resource temporarily unavailable)
3037 sendfile(5, 3, [0], 14021) = 14021
tcpdump shows that after sending the first 11041
bytes, it sends them again. So the second sendfile hasn't advanced
the file pointer at all... which is exactly what you see in the output
of strace.
strace on a 32 bit system shows the offset incrementing nicely:
2396 sendfile(5, 3, [0], 37077) = 12782
2396 sendfile(5, 3, [12782], 24295) = -1 EAGAIN (Resource temporarily unavailable)
2396 sendfile(5, 3, [12782], 24295) = 14480
2396 sendfile(5, 3, [27262], 9815) = -1 EAGAIN (Resource temporarily unavailable)
2396 sendfile(5, 3, [27262], 9815) = 9815
Looks like it's a bug in 2.6.12; 2.6.14 has a little change in arch/x86_64/ia32/sys_ia32.c:
- if (!ret && offset && put_user(of, offset))
+ if (offset && put_user(of, offset))
- Dan
More information about the distcc
mailing list