httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: cvs commit: httpd-2.0/server protocol.c
Date Wed, 21 Mar 2001 15:56:50 GMT
On 20 Mar 2001 trawick@apache.org wrote:

>            if (APR_BRIGADE_EMPTY(b)) {
>   -            if (ap_get_brigade(c->input_filters, b,
>AP_MODE_BLOCKING) != APR_SUCCESS ||
>   +            if ((retval = ap_get_brigade(c->input_filters, b,
>AP_MODE_BLOCKING)) != APR_SUCCESS ||
>                    APR_BRIGADE_EMPTY(b)) {
>   +                apr_brigade_destroy(b);
>   +                if (retval != APR_EOF && retval != APR_TIMEUP) {
>   +                    ap_log_rerror(APLOG_MARK, APLOG_ERR, retval, r,
>"ap_get_brigade() failed");
>   +                }
>                    return -1;

Should apr_brigade_destroy(b) really be called if retval == APR_SUCCESS &&
APR_BRIGADE_EMPTY(b)?  It seems to me at first glance that ap_get_brigade
will probably be called again on b in that case, after it's already been
"destroyed."  Of course, knowing the implementation of
apr_brigade_destroy(), I know that it can get away with that, because b is
allocated from a pool and isn't touched during the destroy; all that
happens is the brigade is cleaned out and the destruction function is
deregistered from the pool.  But do we really want that to happen in a
success case from ap_get_brigade()?  Just checking.

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA



Mime
View raw message