apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 39463] - Sendfile broken in 2.2.2 on Solaris 10 when using Server parsed html includes
Date Tue, 26 Sep 2006 15:45:29 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39463>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39463





------- Additional Comments From dbb@st-andrews.ac.uk  2006-09-26 15:45 -------
Sun think it's a invalid address being passed into sendfilev when the headers
are being added.  The engineer reckons there's a loop to add 0 or more headers,
one file and 0 or more footers, the SEGFAULT happens while adding the headers.

I should be able to look at this again tomorrow, I can try a dtrace against the
process when it succeeds (non Server parsed include) or for different sized
includes.

I've attached some info from the engineer, the fault seems to occur in the for
loop inside senddev_chunk64, the sigcheck function in the dtrace attached
corresponds to the ISSIG macro defined in <sys/proc.h> so it looks like the
segfault occurs for i=2


---------Engineer comments ------------------
I believe what is happening is that the sfv_off part of the sfv struct is of
type off_t (as in the man page for sendfilev). Looking at the header file
<sys/types.h>, we see that off_t is defined as a longlong_t if the
FILE_OFFSET_BITS value is 64bit (i.e. large file aware). I believe this number
has gone negative, and therefore now points to an invalid address within the
process's address space, and hence the EFAULT is returned.

I would suggest that the Apache team (or yourself) put in some code to sanity
check the data going into the sendfilev() system call, or alternatively (which
may be better in your case for now), print out the values passed in if sendfilev
returnes EFAULT.

Maybe the quickest sanity check is to add an assert such as this in the section
of code you pointed me to originally (in the apr_socket_sendfile) function:

    /* Add the headers */
    for (i = 0; i < hdtr->numheaders; i++, curvec++) {
        sfv[curvec].sfv_fd = SFV_FD_SELF;
        sfv[curvec].sfv_flag = 0;
        assert(hdtr->headers[i].iov_base >= 0);
        sfv[curvec].sfv_off = (apr_off_t)hdtr->headers[i].iov_base;
        sfv[curvec].sfv_len = hdtr->headers[i].iov_len;
        requested_len += sfv[curvec].sfv_len;
    }


It wouldn't be foolproof, but would cause Apache to fail when an obviously
negative number is put into the sfv_off field. I'll leave this to you and the
Apache team!


In summary, it would appear that an invalid address is being passed into the
sendfilev system call (the negative numbers), and the kernel is responding as
defined in the man page:

     EFAULT                  The vec argument points to an  ille-
                             gal address.

Granted, the vec argument itself points to a valid address, but the data within
it is not valid, and generates a pagefault - i.e. EFAULT is not unreasonable
given an invalid requested address.

----And

Looking at the dtrace data, we end up in the "for" loop in senddev_chunk64:

    for (i = 0; i < copy_cnt; i++)
    {
        ISSIG(...)
    ...
    }

The ISSIG macro (defined in <sys/proc.h>) results in a call to sigcheck(). The
sigcheck function is called 3 times in all, leading me to believe that the
problem occurs at i=2 in the loop.

Looking at the truss data, we see:

    16912/1:        sendfilev64(1, 17, 0x00285590, 7, 0xFFBFCDAC)   Err#14 EFAULT
    sfv_fd=-2       sfv_flag=0x0    sfv_off=2877088 sfv_len=203
    sfv_fd=-2       sfv_flag=0x0    sfv_off=2767552 sfv_len=4
    sfv_fd=-2       sfv_flag=0x0    sfv_off=-31195136       sfv_len=44
    ...

The third line corresponds with i=2. The offset is negative, and while I'm
prepared to accept that truss is showing a large unsigned value as a signed
value (bug in truss?), converting this to hex (unsigned) gives an address of
0xFE240000 (given SFV_FD_SELF is set for this SFV entry, this is within the
address space of the process itself). 


-----------------------------------------------------




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Mime
View raw message