apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@codemass.com>
Subject Re: Clean break for DYLD now?
Date Fri, 02 Nov 2007 16:29:38 GMT

On Nov 1, 2007, at 6:08 PM, William A. Rowe, Jr. wrote:

> William A. Rowe, Jr. wrote:
>>> We don't test sendfile by default.  Within APR (trunk), simply...
>>> $ cd test
>>> $ make
>>> $ ./sendfile server &
>>> $ ./sendfile client blocking
>>> and you'll see how either the kernel library or the implementation  
>>> (or maybe even the test) is broken.
>> Or (and I should have seen the possibility earlier) an interop flaw  
>> based
>> on CPU or filesystem.  So for the record, the failure I quoted  
>> before about
>> 119880 bytes into the stream was on a journaled, hfs filesystem  
>> running on
>> the G4, retail not server.
> Correction, faults at 119980 bytes into the stream, and I just  
> reproduced the
> flaw on journaled, ufs.

I didn't understand what you meant before, but now I'm seeing the  

It appears that apr_socket_sendfile() (and probably the underlying lib  
or syscall) is updating the &len value-return parameter with the size  
of the file PLUS the size of the trailers. I added some debugging  
output to see what's going on and here's what I got on the client side:

Creating a test file...
Sending the file...
headers[0] size 15
headers[1] size 5
headers[2] size 80000
total headers length 80020
trailers[0] size 19
trailers[1] size 10
trailers[2] size 90000
total trailers length 90029
total iov length 170049
calling apr_socket_sendfile() with len 200000
apr_socket_sendfile() updated offset with 0
apr_socket_sendfile() updated len with 290029
bytes really sent: 370049
apr_socket_sendfile() didn't report the correct number of bytes sent!

As you can see, the returned len == 290029, which is the same as the  
file size (200000) + the trailers size (90029). If the syscall is  
returning this then it's a kernel bug since it's a change in the  
Darwin sendfile semantics.

Now I'll see if I can get this fancy new dtrace stuff to report the  
syscall results...


View raw message