httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: Fw: [PATCH] mod_proxy infinite cpu eating loop
Date Wed, 02 Jan 2002 19:14:27 GMT
On Wed, Jan 02, 2002 at 01:34:57PM -0500, Bill Stoddard wrote:
> I see this pattern several places in the code:
> 
> rc = apr_get_brigade();
> if (rc != APR_SUCCESS) {
>    fail;
> }
> /* Is the brigade empty? */
> if (APR_BRIGADE_EMPTY(b)) {
>    fail;
> }
> /* Get first bucket */
> e = APR_BRIGADE_FIRST(b);
> 
> /* Is the bucket an EOS? */
> if (APR_BUCKET_IS_EOS(e)) {
> }
> 
> /* Does the bucket have zero length? */
> if (e->length == 0) {
> }
> 
> You have to make these checks each and everytime we fetch a brigade which seems
> unintuitive. Should a apr_bucket_read() call on a bucket with e->length == 0 cause
a seg
> fault? Seems this check is masking a deeper problem.

Yeah, this is wonky, but a brigade-using function *should* be able to
handle a 0-length bucket.  I can't imagine why it shouldn't.

However, when the socket bucket disappears in apr_bucket_read, we often
morph it to an immortal bucket of length 0.  What I'm not sure is if 
that happens to get returned by core_input_filter or not - this 
morning, I'm thinking it doesn't.  Last night, I thought it did.

Last night, I did remove one of the cases where the 0-length bucket
is inserted into the returned brigade.  But, I think the socket may
still muck things up.  -- justin


Mime
View raw message