You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@apr.apache.org by bu...@apache.org on 2009/10/21 20:30:39 UTC

DO NOT REPLY [Bug 48029] httpd-2.2.14 hangs in port_getn

https://issues.apache.org/bugzilla/show_bug.cgi?id=48029

--- Comment #1 from Jeff Trawick <tr...@apache.org> 2009-10-21 11:30:34 UTC ---
This log message means port_getn() is returning EAGAIN:

(11)Resource temporarily unavailable: poll failed waiting for CGI child

EAGAIN isn't a documented return code for port_getn(), and APR doesn't handle
it.  (I see that libevent had to start handling it at one point.)

Since EAGAIN wasn't expected by APR, it gets passed back as-is to
cgi_bucket_read() as some arbitrary system error code.

Since EAGAIN wasn't expected by cgi_bucket_read(), it gets passed back as-is up
the filter chain as some arbitrary system error code.  Up the filter chain in
ap_content_length_filter(), EAGAIN is checked for (though it is supposed to
mean something else).  That causes the data read already to be flushed, then a
blocking bucket read is performed.

The read() which returns 0, where you ask "why 0? where has the rest of my cgi
output gone?" is a read on your script's stderr.  The apr_pollset_remove is
supposed to be for the stderr handle, since we've already hit EOF on it.

Does the final port_getn() hang for the amount specified by your Timeout
directive?  (300 is the default)

I'm wildly guessing for the moment that there's some bug with the pollset
manipulation such that the final port_getn() isn't looking at the right handle,
and the cgi process remains as a zombie until the pipe it shares with the httpd
child is emptied.  Maybe we'd avoid the mishandling except for the bogus
EAGAIN.

Can you get a truss showing the httpd child process and the cgi script?  (truss
-fp pid-of-httpd-blocked-in-poll before sending the request)

I'll try to model it more closely here.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org