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.
Thoughts?
----- Original Message -----
From: "Adam Sussman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 01, 2002 9:35 PM
Subject: Re: [PATCH] mod_proxy infinite cpu eating loop
>
> Bill,
>
> Everything looks good except that ap_proxy_string_read() now segfaults on
> its apr_bucket_read(). It appears that APR_BRIGADE_EMPTY is not sufficient
> to detect the case of the closed socket with no data. I suspect that this
> is because the core filter seeds the brigade with a socket bucket and that
> this is what is giving apr_bucket_read problems.
>
> This bit of code seems to do the trick, but again I am still a little unsure
> of my footing with filters and buckets.
>
> -adam
>
>
> Index: proxy_util.c
> ===================================================================
> RCS file: /home/cvspublic/httpd-2.0/modules/proxy/proxy_util.c,v
> retrieving revision 1.75
> diff -u -r1.75 proxy_util.c
> --- proxy_util.c 31 Dec 2001 20:43:59 -0000 1.75
> +++ proxy_util.c 2 Jan 2002 01:29:58 -0000
> @@ -1031,7 +1031,13 @@
> if (APR_BUCKET_IS_EOS(e)) {
> *eos = 1;
> }
> + else if (e->length == 0) {
> + APR_BUCKET_REMOVE(e);
> + apr_bucket_destroy(e);
> + break;
> + }
> else {
> +
> if (APR_SUCCESS != apr_bucket_read(e, (const char **)&response,
>&len,
APR_BLOCK_READ)) {
> return rv;
> }
>
