DO NOT REPLY [Bug 20695] New: - deadlock when mod_proxy used with mod_ext_filter

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20695>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20695

deadlock when mod_proxy used with mod_ext_filter

           Summary: deadlock when mod_proxy used with mod_ext_filter
           Product: Apache httpd-2.0
           Version: 2.0.46
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: Major
          Priority: Other
         Component: mod_ext_filter
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: david.jeschke@pobox.com


If you set up Apache to filter mod_proxy output using mod_ext_filter then an 
Apache thread and the filter process will deadlock in the cases where the 
proxied http response exceed one bucket.  

This occurs on the Windows NT/2K/XP platform.  I did not test the behavior on 
other platforms.

The deadlock occurs because:

mod_proxy's ap_proxy_http_process_response calls
ap_pass_brigade which calls
mod_ext_filter's ef_output_filter which calls
apr_file_read 
which blocks on WaitForSingleObject(.., INFINITE) because the pipe timeout is 
set to minus 1.

At this point Apache is waiting for the filter process to produce output but 
the filter process is waiting for Apache's ap_proxy_http_process_response to 
resume and provide more input.  Deadlock!

It appears that this problem can be solved by setting the timeout on the 
filter process's stdout to zero.  Immediately after the apr_proc_create() call 
in init_ext_filter_process() I put the following:

    /* don't block on reading from child's stdout */
    rc = apr_file_pipe_timeout_set(ctx->proc->out, 0);
    ap_assert(rc == APR_SUCCESS);

and it eliminated the deadlock because then apr_file_read will return 
APR_STATUS_IS_EAGAIN when there is no more output from the filter process 
rather than blocking.

I'm not familiar enough to know whether this problem affects other platforms 
or whether this suggested fix will adversely affect other platforms.

I hope this helps!

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