Hi,
I've recompiled the server with only the proxy and the core modules :
Compiled in modules:
core.c
mod_proxy.c
proxy_connect.c
proxy_ftp.c
proxy_http.c
prefork.c
http_core.c
But the problem remains :
[Thu Sep 05 10:04:55 2002] [info] (32)Broken pipe: core_output_filter:
Peter Van Biesen wrote:
Does anybody have another idea for me to try ?
Have you tried the latest fix for the client_block stuff, I think I saw
a very recent CVS checkin...?
There could of course be more than one leak, and we'll only fix the
problem once all of them are found...
Regards,
Peter Van Biesen wrote:
Hi,
I've recompiled the server with only the proxy and the core modules :
But the problem remains :
Does anybody have another idea for me to try ?
There was a fix for http_protocol.c last night that addressed
at least one problem that could cause the proxy to run
Graham Leggett [EMAIL PROTECTED] writes:
Peter Van Biesen wrote:
Does anybody have another idea for me to try ?
Have you tried the latest fix for the client_block stuff, I think I saw
a very recent CVS checkin...?
There could of course be more than one leak, and we'll only fix the
Joe Schaefer wrote:
There's also a refcount problem in http_protocol.c wrt chunked
transfer codings. The problem is that the bucket holding the
chunk size isn't ever freed, so the corresponding data block
is overcounted.
Here's a diff for http_protocol.c against current anon-cvs (which
doesn't
Recompiled and tested, the problem remains ... :
[Wed Sep 04 13:22:27 2002] [info] Server: Apache/2.0.41-dev, Interface:
mod_ssl/2.0.41-dev, Library: OpenSSL/0.9.6c
[Wed Sep 04 13:22:27 2002] [notice] Apache/2.0.41-dev (Unix)
mod_ssl/2.0.41-dev OpenSSL/0.9.6c DAV/2 configured -- resuming normal
Peter Van Biesen wrote:
Recompiled and tested, the problem remains ... :
[Wed Sep 04 13:22:27 2002] [info] Server: Apache/2.0.41-dev, Interface:
mod_ssl/2.0.41-dev, Library: OpenSSL/0.9.6c
[Wed Sep 04 13:22:27 2002] [notice] Apache/2.0.41-dev (Unix)
mod_ssl/2.0.41-dev OpenSSL/0.9.6c DAV/2
Peter Van Biesen wrote:
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
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
Hi,
I've checked out the latest version from CVS, but I see there's no
configure script in there. How do I get/generate it ? Do I need it to
compile ?
Thanx,
Peter.
Brian Pane wrote:
Peter Van Biesen wrote:
I've continued to investigate the problem, maybe you know what could
cause it.
Peter Van Biesen wrote:
I've checked out the latest version from CVS, but I see there's no
configure script in there. How do I get/generate it ? Do I need it to
compile ?
Pull the following three from cvs:
- httpd-2.0
- apr
- apr-util
Copy both the apr and apr-util directories to
Peter Van Biesen wrote:
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
Graham Leggett wrote:
Peter Van Biesen wrote:
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
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
That's a bit of a problem for the moment, I've compiled 2.0.40, but
httpd complains at runtime about mod_jk, apparently something has
changed in the module api ... I'm using the last version of the
connectors ( 4.0.4 ). Or is there a newer version somewhere ?
Peter.
Justin Erenkrantz wrote:
I give up, I can't find what's wrong ...
Peter.
Peter Van Biesen wrote:
That's a bit of a problem for the moment, I've compiled 2.0.40, but
httpd complains at runtime about mod_jk, apparently something has
changed in the module api ... I'm using the last version of the
connectors ( 4.0.4
Really?
I've built mod_jk v1.2.0 (i.e. from jtc 4.0.4 sources) against 2.0.40 on
Windows, Solaris, and AIX (and HP provides one for 2.0.39 on HPUX, but hasn't
gotten to 2.0.40 last I saw) -- though on AIX I had crashes until Jeff Trawick
helped me navigate the insanity of AIX linking (which
As far as I can see, no ranges supplied. I've downloaded a 'small file'
with my browser :
193.53.20.83 - - [28/Aug/2002:10:33:25 +0200] - GET
http://hpux.cs.utah.edu/ftp/hpux/Gnu/gdb-5.2.1/gdb-5.2.1-sd-11.00.depot.gz
HTTP/1.1 200 7349572
the - is the range.
Since the child crashes, nothing
Hi,
I started my server with MaxClients=1, started the download and attached
to the process with gdb. The process crashed; This is the trace :
vfsi3gdb httpd 7840
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
Hi,
can anybody look into apr_buckets_heap.c ? I'm not familiar with the apr
code, but I don't see the free_func called anywhere ( which frees up the
memory ), or am I mistaken ?
Thanks !
Peter.
Peter Van Biesen wrote:
Hi,
I started my server with MaxClients=1, started the download and
Euh, in function apr_bucket_heap_make . Sorry.
Peter Van Biesen wrote:
Hi,
can anybody look into apr_buckets_heap.c ? I'm not familiar with the apr
code, but I don't see the free_func called anywhere ( which frees up the
memory ), or am I mistaken ?
Thanks !
Peter.
Peter Van
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
At 03:41 AM 8/28/2002, Peter Van Biesen wrote:
As far as I can see, no ranges supplied. I've downloaded a 'small file'
with my browser :
193.53.20.83 - - [28/Aug/2002:10:33:25 +0200] - GET
http://hpux.cs.utah.edu/ftp/hpux/Gnu/gdb-5.2.1/gdb-5.2.1-sd-11.00.depot.gz
HTTP/1.1 200 7349572
the - is
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
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
However, when downloading a large file from the server itself ( not
using the proxy ), works fine ... either its a problem in the proxy or a
timeout somewhere ( locally is a lot faster ).
Peter.
Dirk-Willem van Gulik wrote:
This look like a filter issue I've seen before; but never could not
Peter Van Biesen wrote:
However, when downloading a large file from the server itself ( not
using the proxy ), works fine ... either its a problem in the proxy or a
timeout somewhere ( locally is a lot faster ).
The proxy is very dumb code, it relies almost exclusively on the
filter code to
At 07:53 AM 8/27/2002, Peter Van Biesen wrote:
What should I call it then ? not-so-tiny-files ? 8-)
Nah... large or big files is just fine :-)
I'm guessing $$$s to OOOs [donuts] that your client is starting
some byteranges somewhere along the way. Try adding the bit
\%{Range}i\ in one of your
28 matches
Mail list logo
