[PATCH] bucket alloc: a simpler approach
While prototyping an apr_allocator_t based implementation for the
bucket allocator, I suddenly realized that there may be a much simpler
way to solve the problem.
The attached implementation handles allocation requests differently
based on their size:
* Anything <= 128 bytes is allocated from a free list of 128-byte
blocks contained within the bucket allocator. When the free list
runs out of blocks, the bucket allocator gets additional memory
from its pool. (We can do this because the allocator's lifetime
is the same as that of the pool from which it was created.)
* Anything > 128 bytes is handled using malloc/free. The only
common case larger than 128 is 8192. It would be easy to add
a second free list within the allocator for 8192-byte blocks.
For this free list, we should probably impose a max size, so
that we never store more than two or three 8KB blocks in an
allocator.
Comments...?
--Brian
Index: srclib/apr-util/buckets/apr_buckets_alloc.c
===
RCS file: /home/cvs/apr-util/buckets/apr_buckets_alloc.c,v
retrieving revision 1.3
diff -u -r1.3 apr_buckets_alloc.c
--- srclib/apr-util/buckets/apr_buckets_alloc.c 29 Mar 2002 22:45:45 - 1.3
+++ srclib/apr-util/buckets/apr_buckets_alloc.c 30 Mar 2002 06:41:20 -
@@ -55,24 +55,31 @@
#include
#include "apr_buckets.h"
-/*
- * XXX: this file will be filled in later
- */
+typedef struct bucket_alloc_node_header {
+apr_size_t size;
+apr_bucket_alloc_t *alloc;
+struct bucket_alloc_node_header *next;
+} bucket_alloc_node_header;
+
+#define SMALL_NODE_THRESHOLD 128
+#define NODE_HEADER_SIZE APR_ALIGN_DEFAULT(sizeof(bucket_alloc_node_header))
+
-/* XXX: Remove the ifdef when the struct is filled in.
- * An empty struct causes a compiler error on NetWare
- */
-#ifndef NETWARE
/** A list of free memory from which new buckets or private bucket
* structures can be allocated.
*/
struct apr_bucket_alloc_t {
+apr_pool_t *pool;
+bucket_alloc_node_header *small_nodes;
};
-#endif
APU_DECLARE(apr_bucket_alloc_t *) apr_bucket_alloc_create(apr_pool_t *p)
{
-return (apr_bucket_alloc_t *)0xFECCFECC;
+apr_bucket_alloc_t *list =
+(apr_bucket_alloc_t *)apr_palloc(p, sizeof(*list));
+list->pool = p;
+list->small_nodes = NULL;
+return list;
}
APU_DECLARE(void) apr_bucket_alloc_destroy(apr_bucket_alloc_t *list)
@@ -81,10 +88,37 @@
APU_DECLARE(void *) apr_bucket_alloc(apr_size_t size, apr_bucket_alloc_t *list)
{
-return malloc(size);
+bucket_alloc_node_header *node;
+if (size <= SMALL_NODE_THRESHOLD) {
+node = list->small_nodes;
+if (node) {
+list->small_nodes = node->next;
+}
+else {
+node = (bucket_alloc_node_header *)apr_palloc(list->pool,
+ NODE_HEADER_SIZE +
+ SMALL_NODE_THRESHOLD);
+node->alloc = list;
+node->size = SMALL_NODE_THRESHOLD;
+}
+}
+else {
+node = (bucket_alloc_node_header *)malloc(size + NODE_HEADER_SIZE);
+node->alloc = NULL;
+node->size = size;
+}
+return ((char *)node) + NODE_HEADER_SIZE;
}
APU_DECLARE(void) apr_bucket_free(void *block)
{
-free(block);
+bucket_alloc_node_header *node = (bucket_alloc_node_header *)
+(((char *)block) - NODE_HEADER_SIZE);
+if (node->size <= SMALL_NODE_THRESHOLD) {
+node->next = node->alloc->small_nodes;
+node->alloc->small_nodes = node;
+}
+else {
+free(node);
+}
}
[PATCH] make mod_proxy not accept HTTP/0.9
This patch adds a configuration directive "ProxyRequireValidHTTPStatus".
When enabled, mod_proxy will require a valid HTTP status line from the
destination server and throw a 502 Bad Gateway error if it does not
get it. Basicaly, this disallows backasswards reponses.
Why would one want to do this? Well, I have a setup where my handler
is first attempting one proxy destination, and if that does not work,
it tries another. It works by discarding the output of any response
that isn't a 200 and then trying another gateway.
If the gateway doesn't return a valid HTTP 1.0 or better status line,
mod_proxy assumes a 200 OK response. In my environment, I control all
the gateway servers so I know that a working gateway will always give
me a real HTTP status line. If it doesn't, I want to consider it a
bad gateway and try another.
-adam
Index: mod_proxy.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/proxy/mod_proxy.c,v
retrieving revision 1.76
diff -u -r1.76 mod_proxy.c
--- mod_proxy.c 21 Mar 2002 12:05:45 - 1.76
+++ mod_proxy.c 30 Mar 2002 01:40:52 -
@@ -502,6 +502,7 @@
ps->preserve_host =0;
ps->timeout=0;
ps->timeout_set=0;
+ps->require_valid_http_status=0;
return ps;
}
@@ -833,6 +834,16 @@
}
static const char *
+set_require_valid_http_status(cmd_parms *parms, void *dummy, int flag)
+{
+proxy_server_conf *psf =
+ap_get_module_config(parms->server->module_config, &proxy_module);
+
+psf->require_valid_http_status = flag;
+return NULL;
+}
+
+static const char *
set_recv_buffer_size(cmd_parms *parms, void *dummy, const char *arg)
{
proxy_server_conf *psf =
@@ -1041,6 +1052,8 @@
AP_INIT_TAKE1("ProxyTimeout", set_proxy_timeout, NULL, RSRC_CONF,
"Set the timeout (in seconds) for a proxied connection. "
"This overrides the server timeout"),
+AP_INIT_FLAG("ProxyRequireValidHTTPStatus", set_require_valid_http_status, NULL,
+RSRC_CONF,
+ "on if proxy should not accept reponses that don't give a valid HTTP 1.0 (or
+better) status line"),
{NULL}
};
Index: mod_proxy.h
===
RCS file: /home/cvspublic/httpd-2.0/modules/proxy/mod_proxy.h,v
retrieving revision 1.76
diff -u -r1.76 mod_proxy.h
--- mod_proxy.h 13 Mar 2002 20:47:53 - 1.76
+++ mod_proxy.h 30 Mar 2002 01:40:52 -
@@ -196,6 +196,8 @@
int timeout;
int timeout_set;
+int require_valid_http_status;
+
} proxy_server_conf;
typedef struct {
Index: proxy_http.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/proxy/proxy_http.c,v
retrieving revision 1.138
diff -u -r1.138 proxy_http.c
--- proxy_http.c21 Mar 2002 12:05:45 - 1.138
+++ proxy_http.c30 Mar 2002 01:40:52 -
@@ -730,6 +730,12 @@
p_conn->close += 1;
origin->keepalive = 0;
}
+} else if (conf->require_valid_http_status) {
+apr_socket_close(p_conn->sock);
+backend->connection = NULL;
+return ap_proxyerror(r, HTTP_BAD_GATEWAY,
+apr_pstrcat(p, "Corrupt status line returned by remote "
+"server: ", buffer, NULL));
} else {
/* an http/0.9 response */
backasswards = 1;
Re: bucket free list breakage (was Re: cvs commit:httpd-2.0/server/mpm/workerworker.c)
On Fri, 29 Mar 2002, Cliff Woolley wrote: > Yes. The SSLProxyEngine on directive is missing from the config file. I > added it manually and it works. I expect something like this would do the > trick: oh duh, i had made the change but didn't commit. glad to hear it works.
Re: bucket free list breakage (was Re: cvs commit:httpd-2.0/server/mpm/workerworker.c)
On Fri, 29 Mar 2002, Doug MacEachern wrote: > > PS: I now pass all httpd-test tests except these: > > http.t fails for me too, has for a while. > proxy.t passes for me, but this is new stuff. anything interesting in the > error_log? Yes. The SSLProxyEngine on directive is missing from the config file. I added it manually and it works. I expect something like this would do the trick: Index: proxyssl.conf.in === RCS file: /home/cvs/httpd-test/perl-framework/t/conf/ssl/proxyssl.conf.in,v retrieving revision 1.1 diff -u -d -r1.1 proxyssl.conf.in --- proxyssl.conf.in29 Mar 2002 17:12:19 - 1.1 +++ proxyssl.conf.in29 Mar 2002 23:54:15 - @@ -9,6 +9,9 @@ ProxyPass/ https://@proxyssl_url@/ ProxyPassReverse / https://@proxyssl_url@/ + +SSLProxyEngine on + But does it need some crud in there too? --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: bucket free list breakage (was Re: cvs commit:httpd-2.0/server/mpm/workerworker.c)
On Fri, 29 Mar 2002, Cliff Woolley wrote: > Okay, fixed. excellent, thanks. > PS: I now pass all httpd-test tests except these: http.t fails for me too, has for a while. proxy.t passes for me, but this is new stuff. anything interesting in the error_log?
Re: bucket free list breakage (was Re: cvs commit:httpd-2.0/server/mpm/workerworker.c)
On Fri, 29 Mar 2002, Cliff Woolley wrote: > > filled memory. This obviously causes us to fault. I haven't yet been > > able to determine where an uninitialized node is being inserted into the > > list. All I know is that the base contains a non-NULL terminated > > string, alloc_len contains the length of the string and free_func is > > uninitialized. Okay, fixed. We were forgetting to set free_func in the pool buckets case. pool_make subsumes the logic of heap_make, so anything you do in heap_make must be done in pool_make as well. Unfortunately pool_make can't just call heap_make because heap_make allocates too little space for the bucket type-specific data structure as far as pool buckets are concerned. I added a comment on heap_make warning of this for the future. Thanks for catching this! --Cliff PS: I now pass all httpd-test tests except these: Failed Test Status Wstat Total Fail Failed List of Failed ssl/http.t 11 100.00% 1 ssl/proxy.t11 100.00% 1 ssl/http.t has failed forever, and I don't know what's up with ssl/proxy.t, since you just added that today. Will check on it. -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: [PATCH] HTTP proxy, ab, and Host: as a hop-by-hop header?
Yes - our mails crossed - quite some change between earlier drafts and the final RFC2616 which has little guidance for proxies. Dw. -- Dirk-Willem van Gulik On Fri, 29 Mar 2002, Chuck Murcko wrote: > For HTTP 1.1 you should use the Host: urlhost[:urlport] form. AFAICS > these are the simplest possible proxy requests: > > HTTP 1.0: > GET http://www.ibm.com/ HTTP/1.0 > > > HTTP 1.1: > GET http://www.ibm.com/ HTTP/1.1 > Host: www.ibm.com > > > Chuck > > On Friday, March 29, 2002, at 02:41 PM, [EMAIL PROTECTED] wrote: > > > > > Actually: > > > >> The problem I'm encountering is that ab(1) generates Host: header > >> pointing to proxy server instead of real destination host. > >> Due to this behavior, proxy server (not mod_proxy, BTW) is failing > >> to send a valid HTTP request to destintion webserver using name-based > >> virtualhost, as it simply passes Host: header with its (proxy > >> server's) hostname in it. > > > > I am double checking the spec. To verify what exactly should be send - > > as > > one could also have to consider a proxy on a vhost. > > > > To summarize, in the case of a PROXY we have > > > > proxyhost + proxyport > > full URL (http://urlhost:urlport/foo) (or ftp, etc) > > > > and we do > > > > connect to proxyhost, proxyport > > then say 'GET full-URL HTTP...' > > > > And now the question is, do we do > > > > Host: proxyhost [:proxyport] > > or > > Host: urlhost[:urlport] > > or > > (i.e. explictly NO Host:). > > > > Dw > > > >
Host: header and proxy
Some advice needed on how to use the Host header when using a proxy and
confirming its limitations with respect to Host: based proxies.
- Consider a proxy proxy.com on port PA
- Consider an origin server or gateway on server.com on port PB
- Consider a URL: http://server.com[:PB]/foo.html
>From RFC 2616 - 14.23 - the Host header MUST reprsent the naming authority
of the origin server. (And one MUST use the Host: header when one is doing
HTTP/1.1 (19.6.1.1 - assuming it applies to a client doing a proxy
request)).
So I need to do
tcp-connect( IP-of("proxy.com"), PA)
send(
GET http://server.com:PB/foo.html HTTP/1.1
Host: server.com:PB
...
And the proxy MUST discard the Host: header according to 5.2.1 as there
is an absoluteURI.
So questions
- This is correct ?
- Now how I connect to a Host: based proxy ?
-> seems impossible.
- Why is the Host: header there in this case - as it adds
no information and it only can cause conflicts (i.e.
an application for getting about 5.2.1).
I.e. it seems to make that it almost makes more sense to do
as a client during a proxy request:
connect( IPof("proxy.com"), PA)
send(
GET http://server.com/foo.html HTTP/1.1
[Proxy-]Host: proxy.com:PA
.
much along the lines of Proxy-Authenticate et.al.
DW
--
Dirk-Willem van Gulik
Re: [PATCH] HTTP proxy, ab, and Host: as a hop-by-hop header?
For HTTP 1.1 you should use the Host: urlhost[:urlport] form. AFAICS these are the simplest possible proxy requests: HTTP 1.0: GET http://www.ibm.com/ HTTP/1.0 HTTP 1.1: GET http://www.ibm.com/ HTTP/1.1 Host: www.ibm.com Chuck On Friday, March 29, 2002, at 02:41 PM, [EMAIL PROTECTED] wrote: > > Actually: > >> The problem I'm encountering is that ab(1) generates Host: header >> pointing to proxy server instead of real destination host. >> Due to this behavior, proxy server (not mod_proxy, BTW) is failing >> to send a valid HTTP request to destintion webserver using name-based >> virtualhost, as it simply passes Host: header with its (proxy >> server's) hostname in it. > > I am double checking the spec. To verify what exactly should be send - > as > one could also have to consider a proxy on a vhost. > > To summarize, in the case of a PROXY we have > > proxyhost + proxyport > full URL (http://urlhost:urlport/foo) (or ftp, etc) > > and we do > > connect to proxyhost, proxyport > then say 'GET full-URL HTTP...' > > And now the question is, do we do > > Host: proxyhost [:proxyport] > or > Host: urlhost[:urlport] > or >(i.e. explictly NO Host:). > > Dw >
Re: bucket free list breakage (was Re: cvs commit:httpd-2.0/server/mpm/workerworker.c)
On Fri, 29 Mar 2002, Brad Nicholes wrote: > filled memory. This obviously causes us to fault. I haven't yet been > able to determine where an uninitialized node is being inserted into the > list. All I know is that the base contains a non-NULL terminated > string, alloc_len contains the length of the string and free_func is > uninitialized. I'm looking into this right now. I'll report back ASAP. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: bucket free list breakage (was Re: cvs commit: httpd-2.0/server/mpm/workerworker.c)
On Fri, 29 Mar 2002, Brian Pane wrote:
> Does the rest of *h look valid? (That could help us differentiate memory
> corruption from some code path that just forgot to set h->free_func.)
(gdb) p *h
$1 = {refcount = {refcount = 0},
base = 0x824f568 "mod_include test(\026/@\021", alloc_len = 16,
free_func = 0}
(gdb) p h
$2 = (apr_bucket_heap *) 0x824f5f0
i checked in a test early this morning that triggers the bug,
t/modules/include2.t
t/php/virtual.t also has the same problem.
Re: bucket free list breakage (was Re: cvs commit:httpd-2.0/server/mpm/workerworker.c)
I think I am running into the same problem. What I am seeing is that there is an apr_bucket_heap node on the list that has never been completely initialized. When memory is allocated on our platform, the debug code is filling the memory with a specific string. I can tell that the apr_bucket_heap node has never been completely initialized because the actual value of free_func is still set to the original debug filled memory. This obviously causes us to fault. I haven't yet been able to determine where an uninitialized node is being inserted into the list. All I know is that the base contains a non-NULL terminated string, alloc_len contains the length of the string and free_func is uninitialized. Brad Brad Nicholes Senior Software Engineer Novell, Inc., a leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Friday, March 29, 2002 1:28:03 PM >>> Doug MacEachern wrote: >just looked a bit more, the problem is related to heap buckets and the >free functions. something is broken for sure. i could probably bandaid, >but cliff if you take a look, i'm assuming the right fix would be obvious >to you. > >#1 0x4001cf76 in heap_destroy (data=0x824f758) >at >/home/dougm/apache/farm/src/httpd-2.0-cvs/srclib/apr-util/buckets/apr_buckets_heap.c:74 >74 (*h->free_func)(h->base); >(gdb) p f->free_func >No symbol "f" in current context. >(gdb) p h->free_func >$1 = (void (*)()) 0 > The free_func definitely should be non-null here. It should point to either free() or apr_bucket_free(). Does the rest of *h look valid? (That could help us differentiate memory corruption from some code path that just forgot to set h->free_func.) --Brian
Re: bucket free list breakage (was Re: cvs commit: httpd-2.0/server/mpm/workerworker.c)
Doug MacEachern wrote: >just looked a bit more, the problem is related to heap buckets and the >free functions. something is broken for sure. i could probably bandaid, >but cliff if you take a look, i'm assuming the right fix would be obvious >to you. > >#1 0x4001cf76 in heap_destroy (data=0x824f758) >at >/home/dougm/apache/farm/src/httpd-2.0-cvs/srclib/apr-util/buckets/apr_buckets_heap.c:74 >74 (*h->free_func)(h->base); >(gdb) p f->free_func >No symbol "f" in current context. >(gdb) p h->free_func >$1 = (void (*)()) 0 > The free_func definitely should be non-null here. It should point to either free() or apr_bucket_free(). Does the rest of *h look valid? (That could help us differentiate memory corruption from some code path that just forgot to set h->free_func.) --Brian
bucket free list breakage (was Re: cvs commit: httpd-2.0/server/mpm/workerworker.c)
just looked a bit more, the problem is related to heap buckets and the free functions. something is broken for sure. i could probably bandaid, but cliff if you take a look, i'm assuming the right fix would be obvious to you. #1 0x4001cf76 in heap_destroy (data=0x824f758) at /home/dougm/apache/farm/src/httpd-2.0-cvs/srclib/apr-util/buckets/apr_buckets_heap.c:74 74 (*h->free_func)(h->base); (gdb) p f->free_func No symbol "f" in current context. (gdb) p h->free_func $1 = (void (*)()) 0
Re: [PATCH] HTTP proxy, ab, and Host: as a hop-by-hop header?
Actually: > The problem I'm encountering is that ab(1) generates Host: header > pointing to proxy server instead of real destination host. > Due to this behavior, proxy server (not mod_proxy, BTW) is failing > to send a valid HTTP request to destintion webserver using name-based > virtualhost, as it simply passes Host: header with its (proxy > server's) hostname in it. I am double checking the spec. To verify what exactly should be send - as one could also have to consider a proxy on a vhost. To summarize, in the case of a PROXY we have proxyhost + proxyport full URL (http://urlhost:urlport/foo) (or ftp, etc) and we do connect to proxyhost, proxyport then say 'GET full-URL HTTP...' And now the question is, do we do Host: proxyhost [:proxyport] or Host: urlhost[:urlport] or (i.e. explictly NO Host:). Dw
Re: [PATCH] HTTP proxy, ab, and Host: as a hop-by-hop header?
> The problem I'm encountering is that ab(1) generates Host: header > pointing to proxy server instead of real destination host. > Due to this behavior, proxy server (not mod_proxy, BTW) is failing > to send a valid HTTP request to destintion webserver using name-based > virtualhost, as it simply passes Host: header with its (proxy > server's) hostname in it. I am fixing this... but the puzzle I have is that -always- adding a ':80' in the Host: is kind of causing an extra 3 bytes on the wire for each request - which makes it harder to compare the results a runs against each other. Let me puzzle a bit. Dw
Re: [PATCH] TPF Docs: install-tpf.html and readme-tpf.html
On Fri, 29 Mar 2002, David McCreedy wrote: > This patch updates the readme and install files for TPF. > Minor updates to the latest version of the TPF operating system are now > reflected in the documents. > Also, changes to the documents were made so that they now pass W3C > validation for xhtml 1.0 transitional. Thanks. Committed. Joshua.
[PATCH] TPF Docs: install-tpf.html and readme-tpf.html
This patch updates the readme and install files for TPF. Minor updates to the latest version of the TPF operating system are now reflected in the documents. Also, changes to the documents were made so that they now pass W3C validation for xhtml 1.0 transitional. David McCreedy Title: The Apache TPF Port Index: httpd-docs-1.3/htdocs/manual/readme-tpf.html === RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/readme-tpf.html,v retrieving revision 1.11 diff -u -d -b -r1.11 readme-tpf.html --- httpd-docs-1.3/htdocs/manual/readme-tpf.html 2 Oct 2001 11:02:58 - 1.11 +++ httpd-docs-1.3/htdocs/manual/readme-tpf.html 29 Mar 2002 17:39:08 - @@ -3,7 +3,7 @@ - Installing the Apache 1.3 HTTP - Server on TPF + Installing the Apache 1.3 HTTP + Server on TPF @@ -81,9 +83,8 @@ FTP the tarball to your OS/390 UNIX machine using binary - mode: + mode: - activate FTP in an MSDOS window: ftp your.os390.unix.machine.com @@ -108,22 +109,18 @@ Decompress and extract the archived files necessary for compiling - Apache: + Apache: pax -rvzkf os390_unix_filename.tar.Z -o from=ISO8859-1,to=IBM-1047 "*/src" Remove unnecessary subdirectories: - cd apache_1.3.xx/src/os rm -r bs2000 cygwin mpeix netware os2 os390 win32 - - - @@ -174,26 +171,24 @@ Edit src/Configuration. It contains the list and settings of various "Rules" and an additional section at the bottom that determines which modules to compile: - + - - Adjust the Rules and + adjust the rules and EXTRA_CFLAGS|LIBS|LDFLAGS|INCLUDES if you feel - so inclined. + so inclined - Comment out (by preceding the line with a "#") lines + comment out (by preceding the line with a "#") lines corresponding to those modules you DO NOT wish to - include. + include - Uncomment (by removing the initial "#", if present) + uncomment (by removing the initial "#", if present) lines corresponding to those modules you wish to include or add new lines corresponding to any custom modules you - have written. The readme-tpf.html document lists - the modules that have been tested on TPF. + have written (the readme-tpf.html document lists + the modules that have been tested on TPF) The modules placed in the Apache distribution are the @@ -230,8 +225,6 @@ _C89_OPTIONS export in src/os/tpf/TPFExport - - Otherwise: @@ -245,8 +238,6 @@ _C89_OPTIONS export in src/os/tpf/TPFExport - - Without non_socket_select CGI output is buffered and only sent to the browser when the CGI program @@ -276,8 +267,6 @@ _C89_OPTIONS export in src/os/tpf/TPFExport - - Otherwise: @@ -290,17 +279,37 @@ _C89_OPTIONS export in src/os/tpf/TPFExport - - The use of tpf_sawnc allows for a cleaner shutdown of Apache. - + +Indicate if you would like to use the TCP/IP network services database. +(This only applies if you are using TCP/IP native stack.) - Set the TPF environment variables: +If you are on a PUT16 or higher system, or have PJ28195 installed, + you can use the TCP/IP network services database. + To do so, you must do one of the following: + + + + add "#define TPF_HAVE_NSD" to + src/os/tpf/os.h or + + add "-DTPF_HAVE_NSD" to the + _C89_OPTIONS export in src/os/tpf/TPFExport + + + + +See TPF Transmission Control Protocol/Internet Protocol for more information + about the TCP/IP network services database: + http://www.ibm.com/tpf/pubs/tpfpubs.htm. + + + + Set the TPF environment variables: . os/tpf/TPFExport TIP: The @@ -427,11 +436,10 @@ - util_uri.c: Function argument assignment between types "unsigned char*" and "const unsigned char*" is not allowed. - + @@ -494,10 +502,10 @@ Ensure that the program name you are using for Apache has RESTRICT and KEY0 authorization. - zdpat chta (c-c) will + zdpat chta (c-c) will display allocation information. You
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
On Fri, 29 Mar 2002, Cliff Woolley wrote: > On Fri, 29 Mar 2002, Doug MacEachern wrote: > > > fyi: t/php/virtual produces the same stacktrace > > I'll look into this this afternoon. great. probably easier to work with t/modules/include2.t, stacktrace looks like they suffer the same problem. > Has PHP really been updated for the new buckets API already?? yup and modperl-2.0 too.
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
On Fri, 29 Mar 2002, Doug MacEachern wrote: > fyi: t/php/virtual produces the same stacktrace I'll look into this this afternoon. Has PHP really been updated for the new buckets API already?? --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
On Fri, 29 Mar 2002, Doug MacEachern wrote: > not sure if this is related to the bucket list change or mod_includes > changes or what, but i just checked in a test adapted from modperl that > dumps core. stacktrace below from t/TEST t/modules/include2.t fyi: t/php/virtual produces the same stacktrace i have php checked out like so: % cvs -d ... co -rphp_4_1_2 php4 % cd php4 % cvs co -rphp_4_1_2 Zend TSRM % cd sapi/apache2filter % cvs up -A *.[ch] % cd ../../.. % ./buildconf && ./configure --with-apxs2=... && make
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
On Fri, 29 Mar 2002, Doug MacEachern wrote: > another problem after fixing the httpd-test c-modules to compile: > t/apache/passbrigade eats all cpu. have not looked into it. nevermind. i didn't notice the modules had been updated and my cvs commit up-to-date check failed. this test is working fine for me now.
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Line 3186 in mod_include is hit when it has run through the whole brigade and found no tags. It is just forwarding the brigade. This will be the normal case for files that get parsed unnecessarily. This seems to work for me. No brigades are harmed in this process. I suspect that there is another problem, not mod_include this time. :) I'm still tracking a different core dump in mod_include. Hopefully I'll have it fixed soon. Paul J. Reder Doug MacEachern wrote: > not sure if this is related to the bucket list change or mod_includes > changes or what, but i just checked in a test adapted from modperl that > dumps core. stacktrace below from t/TEST t/modules/include2.t > > #0 0x0815a897 in ?? () at eval.c:41 > 41 eval.c: No such file or directory. > in eval.c > #1 0x4001dbe3 in apr_brigade_cleanup (data=0x81c77a0) > at >/home/dougm/apache/farm/src/httpd-2.0-cvs/srclib/apr-util/buckets/apr_brigade.c:86 > #2 0x4001dc3c in apr_brigade_destroy (b=0x81c77a0) > at >/home/dougm/apache/farm/src/httpd-2.0-cvs/srclib/apr-util/buckets/apr_brigade.c:97 > #3 0x0807f731 in core_output_filter (f=0x81c7548, b=0x81c77a0) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/core.c:3758 > #4 0x08075bc0 in ap_pass_brigade (next=0x81c7548, bb=0x81cc418) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:534 > #5 0x08063bce in ap_http_header_filter (f=0x81cfb40, b=0x81cc418) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/modules/http/http_protocol.c:1472 > #6 0x08075bc0 in ap_pass_brigade (next=0x81cfb40, bb=0x81cc418) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:534 > #7 0x08078a0a in ap_content_length_filter (f=0x81cfb28, b=0x81cc418) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/protocol.c:1263 > #8 0x08075bc0 in ap_pass_brigade (next=0x81cfb28, bb=0x81cc498) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:534 > #9 0x4031692f in send_parsed_content (bb=0xb344, r=0x81cf1c0, f=0x81cbad8) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/modules/filters/mod_include.c:3186 > #11 0x08075bc0 in ap_pass_brigade (next=0x81cbad8, bb=0x81cbbf0) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:534 > #12 0x0807e723 in default_handler (r=0x81cf1c0) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/core.c:3247 > #13 0x0806950f in ap_run_handler (r=0x81cf1c0) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/config.c:193 > #14 0x08069b8d in ap_invoke_handler (r=0x81cf1c0) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/config.c:373 > #15 0x080665dd in ap_process_request (r=0x81cf1c0) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/modules/http/http_request.c:261 > #16 0x08061355 in ap_process_http_connection (c=0x81c7270) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/modules/http/http_core.c:291 > #17 0x0807379b in ap_run_process_connection (c=0x81c7270) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/connection.c:85 > #18 0x08073b42 in ap_process_connection (c=0x81c7270, csd=0x81c71a0) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/connection.c:207 > #19 0x08067d6f in child_main (child_num_arg=0) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/mpm/prefork/prefork.c:675 > #20 0x08067ef8 in make_child (s=0x80a5f10, slot=0) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/mpm/prefork/prefork.c:770 > #21 0x08067f6d in startup_children (number_to_start=1) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/mpm/prefork/prefork.c:793 > #22 0x080683a0 in ap_mpm_run (_pconf=0x80a41c0, plog=0x80ce268, s=0x80a5f10) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/mpm/prefork/prefork.c:1016 > #23 0x0806e644 in main (argc=6, argv=0xb654) > at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/main.c:618 > #24 0x401d9507 in __libc_start_main (main=0x806de50 , argc=6, > ubp_av=0xb654, init=0x805eb14 <_init>, fini=0x808cd10 <_fini>, > rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xb64c) > at ../sysdeps/generic/libc-start.c:129 > > > > -- Paul J. Reder --- "The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure." -- Albert Einstein
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
another problem after fixing the httpd-test c-modules to compile: t/apache/passbrigade eats all cpu. have not looked into it.
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
not sure if this is related to the bucket list change or mod_includes changes or what, but i just checked in a test adapted from modperl that dumps core. stacktrace below from t/TEST t/modules/include2.t #0 0x0815a897 in ?? () at eval.c:41 41 eval.c: No such file or directory. in eval.c #1 0x4001dbe3 in apr_brigade_cleanup (data=0x81c77a0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/srclib/apr-util/buckets/apr_brigade.c:86 #2 0x4001dc3c in apr_brigade_destroy (b=0x81c77a0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/srclib/apr-util/buckets/apr_brigade.c:97 #3 0x0807f731 in core_output_filter (f=0x81c7548, b=0x81c77a0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/core.c:3758 #4 0x08075bc0 in ap_pass_brigade (next=0x81c7548, bb=0x81cc418) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:534 #5 0x08063bce in ap_http_header_filter (f=0x81cfb40, b=0x81cc418) at /home/dougm/apache/farm/src/httpd-2.0-cvs/modules/http/http_protocol.c:1472 #6 0x08075bc0 in ap_pass_brigade (next=0x81cfb40, bb=0x81cc418) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:534 #7 0x08078a0a in ap_content_length_filter (f=0x81cfb28, b=0x81cc418) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/protocol.c:1263 #8 0x08075bc0 in ap_pass_brigade (next=0x81cfb28, bb=0x81cc498) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:534 #9 0x4031692f in send_parsed_content (bb=0xb344, r=0x81cf1c0, f=0x81cbad8) at /home/dougm/apache/farm/src/httpd-2.0-cvs/modules/filters/mod_include.c:3186 #11 0x08075bc0 in ap_pass_brigade (next=0x81cbad8, bb=0x81cbbf0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:534 #12 0x0807e723 in default_handler (r=0x81cf1c0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/core.c:3247 #13 0x0806950f in ap_run_handler (r=0x81cf1c0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/config.c:193 #14 0x08069b8d in ap_invoke_handler (r=0x81cf1c0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/config.c:373 #15 0x080665dd in ap_process_request (r=0x81cf1c0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/modules/http/http_request.c:261 #16 0x08061355 in ap_process_http_connection (c=0x81c7270) at /home/dougm/apache/farm/src/httpd-2.0-cvs/modules/http/http_core.c:291 #17 0x0807379b in ap_run_process_connection (c=0x81c7270) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/connection.c:85 #18 0x08073b42 in ap_process_connection (c=0x81c7270, csd=0x81c71a0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/connection.c:207 #19 0x08067d6f in child_main (child_num_arg=0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/mpm/prefork/prefork.c:675 #20 0x08067ef8 in make_child (s=0x80a5f10, slot=0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/mpm/prefork/prefork.c:770 #21 0x08067f6d in startup_children (number_to_start=1) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/mpm/prefork/prefork.c:793 #22 0x080683a0 in ap_mpm_run (_pconf=0x80a41c0, plog=0x80ce268, s=0x80a5f10) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/mpm/prefork/prefork.c:1016 #23 0x0806e644 in main (argc=6, argv=0xb654) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/main.c:618 #24 0x401d9507 in __libc_start_main (main=0x806de50 , argc=6, ubp_av=0xb654, init=0x805eb14 <_init>, fini=0x808cd10 <_fini>, rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xb64c) at ../sysdeps/generic/libc-start.c:129
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
[EMAIL PROTECTED] wrote: >jim 02/03/29 06:33:51 > > Modified:.CHANGES > include scoreboard.h > os/tpf os.c > server scoreboard.c > server/mpm/netware mpm_netware.c > server/mpm/prefork prefork.c > server/mpm/worker worker.c > Log: > The old, legacy (and unused) code in which the scoreboard was totally > and completely contained in a file (SCOREBOARD_FILE) has been > removed. This does not affect scoreboards which are *mapped* to > files using named-shared-memory at all. This implies that scoreboards > must be based, at some level, on native shared memory (mmap, shm_open, > shmget, whatever), but the code has assumed that for quite awhile > now. Having the scoreboard be *based* on a file makes no sense today. > Just one problem: the httpd no longer links. mpm_common.c contains a call to MPM_SYNC_CHILD_TABLE, and for most MPMs that resolves to "(ap_sync_scoreboard_image())" (which no longer exists). --Brian
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
Nevermind. Should have read the rest of my mail before commenting. I see that it has already been fixed. Sorry for the noise. Paul J. Reder wrote: > This is *not* equivalent code. In the deleted line the increment happens > *after* the check. In the replacement line of code the increment happens > during the check. This patch is wrong and should be backed out. > > Paul J. Reder > > [EMAIL PROTECTED] wrote: > >> bnicholes02/03/28 16:39:56 >> >> Modified:modules/filters mod_include.c >> Log: >> Stop the while loop from incrementing twice per iteration before >> checking for >> the NULL terminator. This was causing the while loop to walk off >> the end of any >> string with an odd number of characters. >> Revision ChangesPath >> 1.209 +1 -1 httpd-2.0/modules/filters/mod_include.c >> Index: mod_include.c >> === >> RCS file: /home/cvs/httpd-2.0/modules/filters/mod_include.c,v >> retrieving revision 1.208 >> retrieving revision 1.209 >> diff -u -r1.208 -r1.209 >> --- mod_include.c28 Mar 2002 01:57:03 -1.208 >> +++ mod_include.c29 Mar 2002 00:39:56 -1.209 >> @@ -1179,7 +1179,7 @@ >>return 0; >>#endif >>path += dots; >> -while (*path && *(path++) != '/') >> +while (*path && *(path+1) != '/') >>++path; >>} >>return 1; >> >> >> > > -- Paul J. Reder --- "The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure." -- Albert Einstein
Re: cvs commit: httpd-2.0/modules/filters mod_include.c
This is *not* equivalent code. In the deleted line the increment happens *after* the check. In the replacement line of code the increment happens during the check. This patch is wrong and should be backed out. Paul J. Reder [EMAIL PROTECTED] wrote: > bnicholes02/03/28 16:39:56 > > Modified:modules/filters mod_include.c > Log: > Stop the while loop from incrementing twice per iteration before checking for > the NULL terminator. This was causing the while loop to walk off the end of any > string with an odd number of characters. > > Revision ChangesPath > 1.209 +1 -1 httpd-2.0/modules/filters/mod_include.c > > Index: mod_include.c > === > RCS file: /home/cvs/httpd-2.0/modules/filters/mod_include.c,v > retrieving revision 1.208 > retrieving revision 1.209 > diff -u -r1.208 -r1.209 > --- mod_include.c 28 Mar 2002 01:57:03 - 1.208 > +++ mod_include.c 29 Mar 2002 00:39:56 - 1.209 > @@ -1179,7 +1179,7 @@ >return 0; >#endif >path += dots; > -while (*path && *(path++) != '/') > +while (*path && *(path+1) != '/') >++path; >} >return 1; > > > > > > -- Paul J. Reder --- "The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure." -- Albert Einstein
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
On 29 Mar 2002 [EMAIL PROTECTED] wrote: > jwoolley02/03/29 00:17:26 > > Modified:. damn near everything > Log: > BUCKET FREELISTS > > Add an allocator-passing mechanism throughout the bucket brigades API. Yep, that's it... the beast is finally in. I've tested to the best of my ability with every last module I can compile... and I took a stab in the dark at all of the rest (MPMs, mod_isapi, etc). The MPM changes will hopefully compile at least... in a few cases there's probably a better place to create and destroy the bucket allocator so that we can get the memory recycling benefit out of the thing. For now it doesn't matter because apr_bucket_alloc_create() doesn't do anything. I just needed something to pass in to ap_run_create_connection(). Let me know if anything egregious happened and I'll take care of it... --Cliff
