> -----Ursprüngliche Nachricht----- > Von: Joe Orton [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 7. November 2008 13:11 > An: [email protected] > Betreff: Re: svn commit: r711886 - /httpd/httpd/branches/2.2.x/STATUS > > On Thu, Nov 06, 2008 at 09:58:52PM +0100, Ruediger Pluem wrote: > > What is the problem at all? > > > > mod_proxy_http uses a a conn_rec to communicate with the > backend. It somehow reverses > > the meaning of input and output filters and uses them to > send the request and receive > > the response. In order to use persistent SSL connections to > the backend it is needed > > to keep this conn_rec (and thus its bucket allocator) alive > and tied to the backend > > connection. Thus it is no longer destroyed at the end of a > client request / connection. > > So the conn_rec and especially the bucket allocator for the > backend have a lifecycle > > that is disjoint from the one to the client. Especially it > can happen that due to e.g. > > a faulty backend connection the conn_rec to the backend > *lives* shorter than > > buckets that are still buffered somewhere in the output > filter chain to the client > > (see comments in removed code below). This causes segfaults > when these buckets are > > accessed then or if brigades that contain them get cleaned > up later on due to a parent > > pool cleanup. > > Not sure if I've got my head round this correctly, but... > > Would it be possible to substitute the backend ("fake") conn_rec's > ->bucket_alloc pointer with the "real" > r->connection->bucket_alloc, for > the duration of the request/response to the backend? Wouldn't that > ensure that all the buckets in question exactly have the correct > lifetime?
I though about this as well, but I suppose this is a risky road to take. Keep in mind that mod_ssl and the core network filters below might use this bucket allocator and that we keep this backend connection alive while the front end connection might have died. So we might still have buckets in this backend connection pipe created by the previous request that are dead on the new request. This may cause segfaults when we start using the backend connection again. Regards Rüdiger
