httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <>
Subject Re: Segmentation fault when downloading large files
Date Mon, 02 Sep 2002 08:21:25 GMT
Peter Van Biesen wrote:

>I've continued to investigate the problem, maybe you know what could
>cause it.
>I'm using a proxy chain, a proxy running internally and forwarding all
>requests to an other proxy in the DMZ. Both proxies are identical. It is
>always the internal proxy that crashes; the external proxy has no
>problem downloading large files ( I haven't tested the memory usage yet
>). Therefor, when the proxy connects directly to the site, the memory is
>freed, but when it forwards the request to another proxy, it is not. 
>Anyhow, I'll wait until the 2.0.41 will be released, maybe this will
>solve the problem. Does anybody know when this will be ?

There's no specific date planned for 2.0.41 yet.  My own thinking
is that we should release 2.0.41 "soon," because it contains a few
important performance and reliability fixes (mostly related to cases
where 2.0.40 and prior releases were trying to buffer unreasonably
large amounts of data).  In the meantime, if you have time, can you
try your proxy test case against the current CVS head?  I ran some
reverse-proxy tests successfully today using the latest 2.0.41-dev
code, and it properly streamed large responses without buffering,
but I'm not certain that my test case covered all the code paths
involved in your two-proxy setup.


>Graham Leggett wrote:
>>Brian Pane wrote:
>>>But the memory involved here ought to be in buckets (which can
>>>be freed long before the entire request is done).
>>>In 2.0.39 and 2.0.40, the content-length filter's habit of
>>>buffering the entire response would keep the httpd from freeing
>>>buckets incrementally during the request.  That particular
>>>problem is gone in the latest 2.0.41-dev CVS head.  If the
>>>segfault problem still exists in 2.0.41-dev, we need to take
>>>a look at whether there's any buffering in the proxy code that
>>>can be similarly fixed.
>>The proxy code doesn't buffer anything, it basically goes "get a bucket
>>from backend stack, put the bucket to frontend stack, cleanup bucket,
>>There are some filters (like include I think) that "put away" buckets as
>>the response is handled, it is possible one of these filters is also
>>causing a "leak".
>>        "There's a moon
>>                                        over Bourbon Street
>>                                                tonight..."

View raw message