httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From traw...@apache.org
Subject cvs commit: httpd-2.0/server request.c
Date Thu, 07 Jun 2001 01:24:44 GMT
trawick     01/06/06 18:24:44

  Modified:    server   request.c
  Log:
  implement Ryan's suggested fix for buckets associated with a subrequest
  having private data in the wrong (i.e., subrequest) pool, leading to
  a segfault later in processing the main request
  
  in the patch posted on new-httpd, the temporary brigade was allocated from
  the connection pool; the committed code allocates the brigade from the
  main-request pool, as suggested by Ian Holsman
  
  Revision  Changes    Path
  1.5       +33 -0     httpd-2.0/server/request.c
  
  Index: request.c
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/server/request.c,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- request.c	2001/06/06 12:51:21	1.4
  +++ request.c	2001/06/07 01:24:44	1.5
  @@ -808,7 +808,40 @@
       apr_bucket *e = APR_BRIGADE_LAST(bb);
   
       if (APR_BUCKET_IS_EOS(e)) {
  +        apr_bucket_brigade *tmpbb;
  +
           apr_bucket_delete(e);
  +
  +        if (!APR_BRIGADE_EMPTY(bb)) { /* avoid brigade create/destroy */
  +
  +            /* We need to be certain that any data in a bucket is valid
  +             * after the subrequest pool is cleared.
  +             */ 
  +            tmpbb = apr_brigade_create(f->r->main->pool);
  +            
  +            APR_BRIGADE_FOREACH(e, bb) {
  +                const char *str;
  +                apr_size_t n;
  +                apr_status_t rv;
  +                
  +                rv = apr_bucket_read(e, &str, &n, APR_BLOCK_READ);
  +                /* XXX handle rv! */
  +                
  +                /* This apr_brigade_write does not use a flush function
  +                   because we assume that we will not write enough data
  +                   into it to cause a flush. However, if we *do* write
  +                   "too much", then we could end up with transient
  +                   buckets which would suck. This works for now, but is
  +                   a bit shaky if changes are made to some of the
  +                   buffering sizes. Let's do an assert to prevent
  +                   potential future problems... */
  +                AP_DEBUG_ASSERT(AP_MIN_BYTES_TO_WRITE <=
  +                                APR_BUCKET_BUFF_SIZE);
  +                apr_brigade_write(tmpbb, NULL, NULL, str, n);
  +            }
  +            apr_brigade_destroy(bb);
  +            bb = tmpbb;
  +        }
       }
       return ap_pass_brigade(f->next, bb);
   }
  
  
  

Mime
View raw message