I now have a reproducable error, a httpd which I can recompile ( it's till a 2.0.39 ), so, if anyone wants me to test something, shoot ! Btw, I've seen in the code of ap_proxy_http_request that the variable e is used many times but I can't seem to find a free somewhere ...
I'm sorry I'm not trying to find the error myself, but I haven't got the time to familiarize myself with the apr code ... Peter. "William A. Rowe, Jr." wrote: > > At 07:06 AM 8/28/2002, Graham Leggett wrote: > >Peter Van Biesen wrote: > > > >>>>Program received signal SIGSEGV, Segmentation fault. > >>>>0xc1bfb06c in apr_bucket_alloc () from /opt/httpd/lib/libaprutil.sl.0 > >>>>(gdb) where > >>>>#0 0xc1bfb06c in apr_bucket_alloc () from > >>>>/opt/httpd/lib/libaprutil.sl.0 > >>>>#1 0xc1bf8d18 in socket_bucket_read () from > >>>>/opt/httpd/lib/libaprutil.sl.0 > >>>>#2 0x00129ffc in core_input_filter () > >>>>#3 0x0011a630 in ap_get_brigade () > >>>>#4 0x000bb26c in ap_http_filter () > >>>>#5 0x0011a630 in ap_get_brigade () > >>>>#6 0x0012999c in net_time_filter () > >>>>#7 0x0011a630 in ap_get_brigade () > > > >The ap_get_brigade() is followed by a ap_pass_brigade(), then a > >apr_brigade_cleanup(bb). > > > >What could be happening is that either: > > > >a) brigade cleanup is hosed or leaks > >b) one of the filters is leaking along the way > > Or it simply tries to slurp all 100's of MBs of this huge download. > > As I guessed, we are out of memory. > > Someone asked why I asserted that input filtering still sucks. Heh. > > Bill
