Re: cvs commit: httpd-2.0/modules/filters mod_include.c

[Brian Pane]

I think I have it working now (with the mod_include
changes that I just committed).  Mod_include test #31
in httpd-test is failing, but I think it's a config
problem.

We probably need some more test cases in httpd-test
to validate all the boundary conditions that can occur
in mod_include when SSI directives span multiple buckets
or even multiple brigades.

--Brian


Ian Holsman wrote:

> Cliff Woolley wrote:
>
>> On 24 Feb 2002 [EMAIL PROTECTED] wrote:
>>
>>
>>>  HTTPD-test is failing.
>>>  but it was failing on 2.0.32 version of mod-include as well
>>>
>>
>> Really??  What's the verbose output?  It worked fine for me when I 
>> tested
>> 2.0.32... I'll try it again with HEAD tomorrow.
>>
>> --Cliff
>>
>>
> 2.0.32 is clean
> 2.0.32 + CVS-HEAD of mod-include
>
>
> # testing : GET /modules/include/exec/off/cmd.shtml
> # expected: '[an error occurred while processing this directive]'
> # received: ''
> not ok 8
>
> # testing : GET /modules/include/exec/off/cgi.shtml
> # expected: '[an error occurred while processing this directive]'
> # received: ''
> not ok 30
>
> and we get a core-dump
> in handle_exec/mod_cgi
>
> it looks like the ctx has some bad data
> (gdb) print *ctx
> $6 = {state = PARSED, flags = 11, if_nesting_level = 0, parse_pos = 3, 
> bytes_parsed = 39, status = 0, output_now = 0, head_start_bucket = 0x0,
>   head_start_index = 135541272, tag_start_bucket = 0x0, 
> tag_start_index = 135541272, tail_start_bucket = 0x5, tail_start_index 
> = 135541272,
>   combined_tag = 0x24 , curr_tag_pos = 
> 0xbfffe2a0 "exec", directive_length = 3221217957, tag_length = 4,
>   error_str = 0x1f , error_str_override = 
> 0x80944a0 "[an error occurred while processing this directive]",
>   time_str = 0x0, time_str_override = 0x8093a95 "%A, %d-%b-%Y %H:%M:%S 
> %Z", pool = 0x0, ssi_tag_brigade = 0x8143730, start_seq_pat = 0x8143ba8,
>   start_seq = 0x8141b0c "", start_seq_len = 134822578, end_seq = 0x5 
> , re_string = 0x8093aae "-->", re_result = 
> 0x0}
> (gdb)
>
>

Re: mod_proxy Cache-Control: no-cache= support Apache1.3

[Igor Sysoev]

On Wed, 20 Feb 2002, Graham Leggett wrote:

> Igor Sysoev wrote:
> 
> > 1.3.23 mod_proxy calls ap_proxy_send_fb() and than closes backend.
> > But ap_proxy_send_fb() flushes output to client so it can hang
> > for a long time.
> 
> I have come up with a patch to solve this problem - in theory anyway.
> 
> Can you test it and get back to me with whether it makes a difference or
> not...?
> 
> The patch is being posted separately.

+/* allocate a buffer to store the bytes in */
+/* make sure it is at least IOBUFSIZE, as recv_buffer_size may be zero for
system default */
+buf_size = MAX(recv_buffer_size, IOBUFSIZE);
+buf = ap_palloc(r->pool, buf_size);

There is one drawback in this code. ap_palloc() is not good for
big allocations (I think > 16K) because it stores data and meta-data
together. I had found this when try to allocate memory from pool
for zlib in mod_deflate. zlib needs about 390K - 2*128K + 2*64K + 6K.
After this change Apache had grown up about 2M after about hour
with 50 requests/s. I'm not sure that this growing could continue but
I did not want additional 2M on each Apache.

I use malloc for big allocations, store addresses in array
allocated from pool and set cleanup for this array.
In cleanup I free addresses if they is not free already.
 
Igor Sysoev

Re: cvs commit: httpd-2.0/modules/filters mod_include.c

[Ian Holsman]

Cliff Woolley wrote:
> On 24 Feb 2002 [EMAIL PROTECTED] wrote:
> 
> 
>>  HTTPD-test is failing.
>>  but it was failing on 2.0.32 version of mod-include as well
>>
> 
> Really??  What's the verbose output?  It worked fine for me when I tested
> 2.0.32... I'll try it again with HEAD tomorrow.
> 
> --Cliff
> 
> 
2.0.32 is clean
2.0.32 + CVS-HEAD of mod-include


# testing : GET /modules/include/exec/off/cmd.shtml
# expected: '[an error occurred while processing this directive]'
# received: ''
not ok 8

# testing : GET /modules/include/exec/off/cgi.shtml
# expected: '[an error occurred while processing this directive]'
# received: ''
not ok 30

and we get a core-dump
in handle_exec/mod_cgi

it looks like the ctx has some bad data
(gdb) print *ctx
$6 = {state = PARSED, flags = 11, if_nesting_level = 0, parse_pos = 3, 
bytes_parsed = 39, status = 0, output_now = 0, head_start_bucket = 0x0,
   head_start_index = 135541272, tag_start_bucket = 0x0, tag_start_index 
= 135541272, tail_start_bucket = 0x5, tail_start_index = 135541272,
   combined_tag = 0x24 , curr_tag_pos = 
0xbfffe2a0 "exec", directive_length = 3221217957, tag_length = 4,
   error_str = 0x1f , error_str_override = 
0x80944a0 "[an error occurred while processing this directive]",
   time_str = 0x0, time_str_override = 0x8093a95 "%A, %d-%b-%Y %H:%M:%S 
%Z", pool = 0x0, ssi_tag_brigade = 0x8143730, start_seq_pat = 0x8143ba8,
   start_seq = 0x8141b0c "", start_seq_len = 134822578, end_seq = 0x5 
, re_string = 0x8093aae "-->", re_result = 0x0}
(gdb)

Re: cvs commit: httpd-2.0/modules/filters mod_include.c

[Cliff Woolley]

On 24 Feb 2002 [EMAIL PROTECTED] wrote:

>   HTTPD-test is failing.
>   but it was failing on 2.0.32 version of mod-include as well

Really??  What's the verbose output?  It worked fine for me when I tested
2.0.32... I'll try it again with HEAD tomorrow.

--Cliff

RE: 2.0.32 + PHP 4 CVS

[NAIK,ROSHAN (HP-Cupertino,ex1)]

what is the issue exactly  ?

> -Original Message-
> From: Austin Gonyou [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 21, 2002 4:18 PM
> To: [EMAIL PROTECTED]
> Subject: 2.0.32 + PHP 4 CVS
> 
> 
> There may be some issue with PHP Apache2 SAPI and the worker 
> MPM. Since
> that's what I'm using, and was using before too(fyi). I'm going to
> change the MPM and see what that does. Just wanted to give an update. 
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-698-7250
> email: [EMAIL PROTECTED]
> 
> "It is the part of a good shepherd to shear his flock, not to 
> skin it."
> Latin Proverb
> 

Re: [ANNOUNCE] mod_ssl 2.8.7-1.3.23

[Cliff Woolley]

To what extent are we keeping up with these changes in mod_ssl for apache
2.0?

--Cliff

-- Forwarded message --
Date: Sat, 23 Feb 2002 20:22:15 +0100
From: Ralf S. Engelschall <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: [ANNOUNCE] mod_ssl 2.8.7-1.3.23


Another little round in maintaining mod_ssl 2.x for Apache 1.3.x brings
to you today mod_ssl 2.8.7 for Apache 1.3.23. The corresponding CHANGES
entries follow for your convinience.

Fetch it from:

o http://www.modssl.org/source/
o  ftp://ftp.modssl.org/source/

Yours,
   Ralf S. Engelschall
   [EMAIL PROTECTED]
   www.engelschall.com

  Changes with mod_ssl 2.8.7 (01-Feb-2002 to 23-Feb-2002)

   *) Support for the latest OpenSSL 0.9.7 snapshots.

   *) Fixed potential buffer overflow in DBM and SHMHT session
  cache if very very large certificate chains are used.

   *) Compliance with POSIX 1003.1-2001 (SUSv3) by replacing obsolete
  "head -1" and "tail -1" constructs with sed variants in scripts.

   *) Fixed file descriptor leakage under Win32.

RE: Modules.apache.org development mailing list!

[Ryan Bloom]

> According to Sander van Zoest:
> 
> > It used to be at  and was also
reachable
> > via  but this got lost in the
downtime
> > and office move. We should probably update the IP so
> > mail-archives.apache.org
> > works again. Although most people use MARC now these days anyways.
> 
> I'd prefer to having an 'official' apache.org location for
> all our mail archives.

As I said, I have no problem making archives.apache.org, I just want to
be able to also reach it using archive.covalent.net.

Ryan

Re: has anybody seen worker segfaults?

[Jeff Trawick]

Jeff Trawick <[EMAIL PROTECTED]> writes:

>  t0   we need to fork() a new child for some reason
>  t1   we get the graceful restart prod on the pod BEFORE
>   the start_threads() thread has gotten dispatched and
>   initialized worker_queue
>  t2   we call signal_workers() which tries to use a NULL
>   worker_queue and we segfault
> 
> One possible fix for this is to initialize worker_queue in
> child_main() before creating the start_threads() thread so that there
> is no question that the init has been done before we try to use it.
> 
> But there seem to be other timing issues as well.  Maybe we miss our
> chance to apr_thread_join() a worker thread right before it has been
> created.  A fix that would handle that as well as the first problem
> would be to join the start_threads() thread before trying to process a
> restart request.

After trying this the segfaults go away but we still have some process
bailing out prematurely (still get the accept mutex error, still get a
lot of dropped connections even though nobody is segfaulting).

-- 
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
   http://www.geocities.com/SiliconValley/Park/9289/
 Born in Roswell... married an alien...

Re: Modules.apache.org development mailing list!

[Lars Eilebrecht]

According to Sander van Zoest:

> It used to be at  and was also reachable
> via  but this got lost in the downtime
> and office move. We should probably update the IP so
> mail-archives.apache.org
> works again. Although most people use MARC now these days anyways.

I'd prefer to having an 'official' apache.org location for
all our mail archives.

ciao...
-- 
Lars Eilebrecht  - RFC 527: "Beware the ARPANET, my son;
[EMAIL PROTECTED]   - The bits that byte, the heads that scratch;"

Re: Modules.apache.org development mailing list!!!!

[Sander van Zoest]

On Fri, 22 Feb 2002, Ryan Bloom wrote:

> While we are at it, Covalent has decided to open archives.covalent.net
> so that people can hack on that site as well.  Once we get a group of
> people on the mailing list to discuss how we want to do
> modules.apache.org, we can decide if and how we want to tackle
> archives.covalent.net, and that can include re-naming it to
> archives.apache.org, although Covalent would like to keep an alias to
> archives.covalent.net as well.

It used to be at  and was also reachable
via  but this got lost in the downtime
and office move. We should probably update the IP so mail-archives.apache.org
works again. Although most people use MARC now these days anyways.

Cheers,

--
Sander van Zoest  [EMAIL PROTECTED]
San Diego, CA, US http://Sander.vanZoest.com/

Re: cvs commit: httpd-2.0/modules/test mod_bucketeer.c config.m4

[Justin Erenkrantz]

On Sat, Feb 23, 2002 at 06:43:25AM -, [EMAIL PROTECTED] wrote:
> ianh02/02/22 22:43:25
> 
>   Modified:modules/test config.m4
>   Added:   modules/test mod_bucketeer.c
>   Log:
>   introducing the bucketeer
>   it lets you set up boundry test conditions for things like
>   mod-include

>   1.1  httpd-2.0/modules/test/mod_bucketeer.c
>   
>   Index: mod_bucketeer.c
>   ===

>* Portions of this software are based upon public domain software
>* (zlib functions gz_open and gzwrite)
>*/

I take it that this comment is stale?  -- justin

[PATCH] more filter handle changes

[Ryan Morgan]

There are a couple more instances of ap_add_*_filter in core.c that can be
optimized away using ap_add_*_filter_handle.  This particular block is
in core_pre_connection().

-Ryan

Index: server/core.c
===
RCS file: /home/cvspublic/httpd-2.0/server/core.c,v
retrieving revision 1.151
diff -u -r1.151 core.c
--- server/core.c   21 Feb 2002 17:20:26 -  1.151
+++ server/core.c   23 Feb 2002 08:29:51 -
@@ -3841,8 +3841,10 @@
 net->client_socket = csd;

 ap_set_module_config(net->c->conn_config, &core_module, csd);
-ap_add_input_filter("CORE_IN", net, NULL, net->c);
-ap_add_output_filter("CORE", net, NULL, net->c);
+ap_add_input_filter_handle(ap_core_input_filter_handle, net, NULL,
+   net->c);
+ap_add_output_filter_handle(ap_core_output_filter_handle, net, NULL,
+net->c);
 return DONE;
 }