https://issues.apache.org/bugzilla/show_bug.cgi?id=55643
Bug ID: 55643
Summary: truncated CGI output
Product: Apache httpd-2
Version: 2.4.6
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Core
Assignee: [email protected]
Reporter: [email protected]
Under some circumstances, CGI output will be truncated. The bug is in
server/core_filters.c, around line 542 in the function ap_core_output_filter().
No, really!
The call to send_brigade_blocking() is expected to return APR_SUCCESS,
otherwise the connection to the browser is assumed abandoned. However,
send_brigade_blocking() calls apr_poll(), which calls the system poll(). Under
extremely hard to reproduce on demand circumstances, the poll() call is
interrupted by the SIGCHLD signal from the exiting CGI script, setting errno to
EINTR ('4' on Linux). This value propagates up through apr_poll() and
send_brigade_blocking() into ap_core_output_filter()'s "rv", where the rest of
the output is abandoned, like so:
rv = send_brigade_blocking(net->client_socket, bb,
&(ctx->bytes_written), c);
if (rv != APR_SUCCESS) {
/* The client has aborted the connection */
c->aborted = 1;
return rv;
}
I'll defer to the httpd devs whether this EINTR should be handled at this level
or further down in the stack.
As difficult as this bug is to trigger on purpose, it started showing up
consistently after we upgraded our www cluster (4 RHEL servers) to httpd-2.4.6
in early September 2013, regular enough that we were able to start debugging on
our production hosts. However, it is extremely sensitive to load, network
latency, etc., as you have to get the SIGCHLD signal from the CGI process to
come in during the poll() -- not a very big target window on modern machines
and networks.
Searches turned up dozens of reports over the years that could well be this
bug. In most cases people fiddled with things until the problem went into
hiding, at which point (not surprisingly) they quit working on it. We were
lucky enough that it just wouldn't go away on our systems.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
