httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 36324] - runaway child process stuck in loop in apr_pool_cleanup_kill()
Date Tue, 30 Aug 2005 11:05:37 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=36324>.
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=36324





------- Additional Comments From stuart@terminus.co.uk  2005-08-30 13:05 -------
Apologies for the slight delay replying - I've been away over a long weekend.

> I wonder if this is another manifestation of the subrequest+filter issues 
> discussed re: Bug 17629?  Are you mixing main- and sub-request output streams 
> via different filter configs?  (mod_diagnostics might help find out, if that's 
> a difficult question).

Not sure exactly how you mean "different filter configs", but I suspect yes. We
use mod_include heavily, but our own code sometimes creates additional
subrequests (the ones you see going through mod_proxy in the backtrace above).
These subrequests have a custom input filter (which creates their "request") and
output filter (which may or may not modify the response data) added using
ap_add_input_filter/ap_add_output_filter. The output from those is passed back
up to the originating request (which could be either the main one, or a SSI
generated subrequest, and doesn't have the custom filters).

-- 
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.

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


Mime
View raw message