You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jerry Baker <je...@weirdness.com> on 2001/07/31 23:00:18 UTC
mod_tls and HTTP POST
Apache 2.0.23-dev (from CVS yesterday) with OpenSSL 0.9.6b.
If mod_tls is being used, a POST operation where $ENV{"Content-Length"}
exceeds 570 fails. That is to say that there is nothing sent to STDIN.
This was tried with IE 5.5, Netscape 4.78, and Mozilla 0.9.2.
To test this I set up a form with a single "textarea" and had it "POST"
to a Perl script that simply read STDIN into a scalar ($variable) and
then did a "print $variable". It works fine as long as the content
length < 570. If the content length > 570 then Perl reports $variable as
undefined. If I access the same form without TLS (eg, http instead of
https) then it works fine.
Another oddity with TLS is that with TLS active, accessing the stock
printenv.pl that ships with Apache fails. When accessed via https the
output of that script is truncated.
PS - I am not subscribed to new-httpd because as of the sending of this
message all messages sent to new-httpd-subscribe@apache.org have gone
unanswered.
--
Jerry Baker
PGP Key: http://keyserver.pgp.com/pks/lookup?op=get&search=0x48D96D45
LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/
Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
Re: how to unsubscribe????
Posted by Greg Ames <gr...@remulak.net>.
bilal wrote:
>
> Please can any body till me how to unsubscribe
>
> Best Regards
>
> Eng. Bilal Okour
> Computer Engineer
If you configure Outlook to show you all the e-mail headers (I don't
know how) you will see:
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
send an email to the list-unsubscribe address.
how to unsubscribe????
Posted by bilal <bi...@fapco.net>.
Please can any body till me how to unsubscribe
Best Regards
Eng. Bilal Okour
Computer Engineer
Re: mod_tls and HTTP POST
Posted by Jerry Baker <je...@weirdness.com>.
"William A. Rowe, Jr." wrote:
>
> From: "Jerry Baker" <je...@weirdness.com>
> Sent: Tuesday, July 31, 2001 4:00 PM
>
> > Apache 2.0.23-dev (from CVS yesterday) with OpenSSL 0.9.6b.
> >
> > If mod_tls is being used, a POST operation where $ENV{"Content-Length"}
> > exceeds 570 fails. That is to say that there is nothing sent to STDIN.
> > This was tried with IE 5.5, Netscape 4.78, and Mozilla 0.9.2.
>
> FYI, this also affects mod_ssl.
I am unclear on what was fixed and what wasn't. This is still affecting
mod_ssl as of 2:50am EDT, and mod_tls still crashes as reported in
<3B67C761.6099C9D4%40weirdness.com>. This doesn't affect plain http
access to the same script.
--
Jerry Baker
PGP Key: http://keyserver.pgp.com/pks/lookup?op=get&search=0x48D96D45
LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/
Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
Re: mod_tls and HTTP POST
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Roy T. Fielding" <fi...@ebuilt.com>
Sent: Tuesday, August 07, 2001 10:42 PM
> On Wed, Aug 01, 2001 at 03:09:53AM -0600, Jerry Baker wrote:
> > > Now trying to access a page via https with mod_tls loaded causes Apache
> > > to crash with the following call stack:
>
> I think Bill Rowe fixed this in mod_tls.c rev 1.20. This would have been
> easier to figure out (saving me a couple hours of squinting) if he had
> included an appropriate commitlog message.
Sorry... small time window (between 1.19/1.20), didn't expect the bug reports
to fly all that fast :( ... sure sounds like that could have been the problem.
Jerry, can you still reproduce from the current CVS?
Bill
Re: mod_tls and HTTP POST
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Wed, Aug 01, 2001 at 03:09:53AM -0600, Jerry Baker wrote:
> > Now trying to access a page via https with mod_tls loaded causes Apache
> > to crash with the following call stack:
> >
> Better call stack.
>
> memcpy(unsigned char * 0x00571e98, unsigned char * 0x8cc832c0, unsigned long 766) line 171
> apr_pmemdup(apr_pool_t * 0x00571a88, const void * 0x8cc832c0, unsigned int 766) line 106 + 17 bytes
> churn_output(tls_filter_ctx * 0x00571d70) line 174 + 32 bytes
> churn(tls_filter_ctx * 0x00571d70, int 0, unsigned int * 0x1036dcc4) line 292 + 9 bytes
> tls_in_filter(ap_filter_t * 0x00571d88, apr_bucket_brigade * 0x00571e58, int 0, unsigned int * 0x1036dcc4) line 372 + 17 bytes
> ap_get_brigade(ap_filter_t * 0x00571d88, apr_bucket_brigade * 0x00571e58, int 0, unsigned int * 0x1036dcc4) line 217 + 24 bytes
> ap_http_filter(ap_filter_t * 0x00571e08, apr_bucket_brigade * 0x00574278, int 0, unsigned int * 0x1036dcc4) line 574 + 26 bytes
> ap_get_brigade(ap_filter_t * 0x00571e08, apr_bucket_brigade * 0x00574278, int 0, unsigned int * 0x1036dcc4) line 217 + 24 bytes
> ap_getline(char * 0x1036dd7c, int 8192, request_rec * 0x00573b00, int 0) line 223 + 22 bytes
> read_request_line(request_rec * 0x00573b00) line 396 + 23 bytes
> ap_read_request(conn_rec * 0x00571b70) line 593 + 9 bytes
> ap_process_http_connection(conn_rec * 0x00571b70) line 281 + 9 bytes
> ap_run_process_connection(conn_rec * 0x00571b70) line 82 + 81 bytes
> ap_process_connection(conn_rec * 0x00571b70) line 221
> worker_main(int 249) line 908
> _threadstartex(void * 0x005bf648) line 212 + 13 bytes
> KERNEL32! 77e8758a()
I think Bill Rowe fixed this in mod_tls.c rev 1.20. This would have been
easier to figure out (saving me a couple hours of squinting) if he had
included an appropriate commitlog message.
....Roy
Re: mod_tls and HTTP POST
Posted by Jerry Baker <je...@weirdness.com>.
Jerry Baker wrote:
>
> "William A. Rowe, Jr." wrote:
> >
> > Actually, the last patch was nothing more than formatting changes. I suspect
> > it simply forced mod_tls to be rebuilt, with some success :)
>
> Now trying to access a page via https with mod_tls loaded causes Apache
> to crash with the following call stack:
>
> memcpy(unsigned char * 0x0055ccf8, unsigned char * 0xa1047ab0, unsigned long 766) line 171
> apr_pmemdup(apr_pool_t * 0x0055c8e8, const void * 0xa1047ab0, unsigned int 766) line 106 + 17 bytes
> mod_tls! 6fd812d7()
Better call stack.
memcpy(unsigned char * 0x00571e98, unsigned char * 0x8cc832c0, unsigned long 766) line 171
apr_pmemdup(apr_pool_t * 0x00571a88, const void * 0x8cc832c0, unsigned int 766) line 106 + 17 bytes
churn_output(tls_filter_ctx * 0x00571d70) line 174 + 32 bytes
churn(tls_filter_ctx * 0x00571d70, int 0, unsigned int * 0x1036dcc4) line 292 + 9 bytes
tls_in_filter(ap_filter_t * 0x00571d88, apr_bucket_brigade * 0x00571e58, int 0, unsigned int * 0x1036dcc4) line 372 + 17 bytes
ap_get_brigade(ap_filter_t * 0x00571d88, apr_bucket_brigade * 0x00571e58, int 0, unsigned int * 0x1036dcc4) line 217 + 24 bytes
ap_http_filter(ap_filter_t * 0x00571e08, apr_bucket_brigade * 0x00574278, int 0, unsigned int * 0x1036dcc4) line 574 + 26 bytes
ap_get_brigade(ap_filter_t * 0x00571e08, apr_bucket_brigade * 0x00574278, int 0, unsigned int * 0x1036dcc4) line 217 + 24 bytes
ap_getline(char * 0x1036dd7c, int 8192, request_rec * 0x00573b00, int 0) line 223 + 22 bytes
read_request_line(request_rec * 0x00573b00) line 396 + 23 bytes
ap_read_request(conn_rec * 0x00571b70) line 593 + 9 bytes
ap_process_http_connection(conn_rec * 0x00571b70) line 281 + 9 bytes
ap_run_process_connection(conn_rec * 0x00571b70) line 82 + 81 bytes
ap_process_connection(conn_rec * 0x00571b70) line 221
worker_main(int 249) line 908
_threadstartex(void * 0x005bf648) line 212 + 13 bytes
KERNEL32! 77e8758a()
--
Jerry Baker
PGP Key: http://keyserver.pgp.com/pks/lookup?op=get&search=0x48D96D45
LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/
Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
Re: mod_tls and HTTP POST
Posted by Jerry Baker <je...@weirdness.com>.
"William A. Rowe, Jr." wrote:
>
> Actually, the last patch was nothing more than formatting changes. I suspect
> it simply forced mod_tls to be rebuilt, with some success :)
Now trying to access a page via https with mod_tls loaded causes Apache
to crash with the following call stack:
memcpy(unsigned char * 0x0055ccf8, unsigned char * 0xa1047ab0, unsigned long 766) line 171
apr_pmemdup(apr_pool_t * 0x0055c8e8, const void * 0xa1047ab0, unsigned int 766) line 106 + 17 bytes
mod_tls! 6fd812d7()
Sorry I can't get the stack for mod_tls, but if I build it debug the
crash doesn't happen (the browser just hangs trying to access the page).
--
Jerry Baker
PGP Key: http://keyserver.pgp.com/pks/lookup?op=get&search=0x48D96D45
LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/
Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
Re: mod_tls and HTTP POST
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Actually, the last patch was nothing more than formatting changes. I suspect
it simply forced mod_tls to be rebuilt, with some success :)
----- Original Message -----
From: "Jerry Baker" <je...@weirdness.com>
To: <ne...@apache.org>
Sent: Wednesday, August 01, 2001 1:47 AM
Subject: Re: mod_tls and HTTP POST
> Jerry Baker wrote:
> >
> > This isn't fixing the mod_tls problem. I just pulled at 2:30 EDT and
> > mod_tls still has the same issue while using plain http does not.
> >
> > --
> > Jerry Baker
>
> Sorry I jumped the gun. Another CVS update right after this message was
> sent updated mod_tls.c and it's fixed. Thanks.
>
> --
> Jerry Baker
>
> PGP Key: http://keyserver.pgp.com/pks/lookup?op=get&search=0x48D96D45
>
> LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/
> Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
>
Re: mod_tls and HTTP POST
Posted by Jerry Baker <je...@weirdness.com>.
Jerry Baker wrote:
>
> This isn't fixing the mod_tls problem. I just pulled at 2:30 EDT and
> mod_tls still has the same issue while using plain http does not.
>
> --
> Jerry Baker
Sorry I jumped the gun. Another CVS update right after this message was
sent updated mod_tls.c and it's fixed. Thanks.
--
Jerry Baker
PGP Key: http://keyserver.pgp.com/pks/lookup?op=get&search=0x48D96D45
LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/
Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
Re: mod_tls and HTTP POST
Posted by Jerry Baker <je...@weirdness.com>.
"William A. Rowe, Jr." wrote:
>
> Yup. My bad. I've backed it out. Thank you for finding this!
>
> Bill
This isn't fixing the mod_tls problem. I just pulled at 2:30 EDT and
mod_tls still has the same issue while using plain http does not.
--
Jerry Baker
PGP Key: http://keyserver.pgp.com/pks/lookup?op=get&search=0x48D96D45
LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/
Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
Re: 2.0.23?
Posted by Jeff Trawick <tr...@attglobal.net>.
Cliff Woolley <cl...@yahoo.com> writes:
> On 1 Aug 2001, Jeff Trawick wrote:
>
> > I'm building from HEAD okay on Darwin now.
>
> The two problems were listed along with the other known problem in the
> email I sent to current-testers.
I gotta subscribe there I guess :)
> One was that a certain file in APR failed to link due to some feature
> macro being set incorrectly resulting in APR trying to use functions
> (possibly threading-related? I don't remember off the top of my head) that
> didn't exist on that platform.
ahh, now I recall seeing that... my normal config process does
"--with-mpm=prefork --disable-threads" on darwin and freebsd so I
don't normally see this... I'm looking into it right now...
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: 2.0.23?
Posted by Cliff Woolley <cl...@yahoo.com>.
On 1 Aug 2001, Jeff Trawick wrote:
> > PS: Fixes for the Mac OS X/Darwin problem have still not been committed.
> > It was two problems... one of which was the version of buildconf on
> > icarus, no doubt (hence the old config.guess in the tarball). I'll see
> > what I can do about that. The other problem probably just needs a
> > configure check added or maybe some hints magic... can someone with a
> > Darwin box please do me a favor and fix this the right way, please?
>
> What was the second problem, or what is the subject of messages
> describing the second problem?
>
> I'm building from HEAD okay on Darwin now.
The two problems were listed along with the other known problem in the
email I sent to current-testers.
One was that a certain file in APR failed to link due to some feature
macro being set incorrectly resulting in APR trying to use functions
(possibly threading-related? I don't remember off the top of my head) that
didn't exist on that platform.
The other problem was the old copy of config.guess that was in the
tarball, which presumably got there when I ran buildconf on icarus. I'll
have to figure out how to get icarus to give me a newer config.guess when
I roll the next tarball.
Thanks,
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.23?
Posted by Jeff Trawick <tr...@attglobal.net>.
Cliff Woolley <cl...@yahoo.com> writes:
> PS: Fixes for the Mac OS X/Darwin problem have still not been committed.
> It was two problems... one of which was the version of buildconf on
> icarus, no doubt (hence the old config.guess in the tarball). I'll see
> what I can do about that. The other problem probably just needs a
> configure check added or maybe some hints magic... can someone with a
> Darwin box please do me a favor and fix this the right way, please?
What was the second problem, or what is the subject of messages
describing the second problem?
I'm building from HEAD okay on Darwin now.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: 2.0.23?
Posted by Jerry Baker <je...@weirdness.com>.
Jerry Baker wrote:
>
> --------------------Configuration: libhttpd - Win32 Release--------------------
> Compiling...
> scoreboard.c
> D:\Apache\httpd-2.0\server\scoreboard.c(279) : error C2373: 'ap_update_child_status' : redefinition; different type modifiers
> .\include\scoreboard.h(217) : see declaration of 'ap_update_child_status'
> Error executing cl.exe.
>
> Apache.exe - 1 error(s), 0 warning(s)
>
> --
> Jerry Baker
Fixing /include/scoreboard.h to have the same declaration as
scoreboard.c fixes the building here on Win32.
-------------------------------
scoreboard.h line 217
< int ap_update_child_status(int child_num, int thread_num, int status, request_rec *r);
> AP_DECLARE(int) ap_update_child_status(int child_num, int thread_num, int status, request_rec *r);
--
Jerry Baker
PGP Key: http://keyserver.pgp.com/pks/lookup?op=get&search=0x48D96D45
LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/
Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
Re: 2.0.23?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jerry, I'm not seeing this on any of my five checked out trees. Please try
checking out the trees fresh. Do a single full build (don't clean first or
you will regenerate ssl files from cvs!) and email me the result (if it is
still failing you.)
Bill
----- Original Message -----
From: "Jerry Baker" <je...@weirdness.com>
To: <ne...@apache.org>
Sent: Wednesday, August 01, 2001 1:01 AM
Subject: Re: 2.0.23?
> Cliff Woolley wrote:
> >
> > In the meanwhile, I'd ask everyone to please give 2.0.23-dev a really good
> > shakedown and let's try to make sure any lingering build errors are
> > cleaned up. Sorry if this process has been tedious, but I want this beta
> > to really shine.
>
> Have been unable to build Apache today. Last successful build from CVS
> was approximately 9am EDT. Build fails at libhttpd at service.c where
> the MS compiler simply says:
>
> registry.c
> service.c
> Generating Code...
> Error executing xicl6.exe.
>
> Apache.exe - 1 error(s), 1 warning(s)
>
> xicl6 is a component of the Intel 4.5 C++ compiler that executes the
> MS link.exe or the Intel linker depending. I have never had an issue
> with it until today.
>
> I tried uninstalling the Intel compiler which left me with:
>
> --------------------Configuration: libhttpd - Win32 Release--------------------
> Compiling...
> scoreboard.c
> D:\Apache\httpd-2.0\server\scoreboard.c(279) : error C2373: 'ap_update_child_status' : redefinition; different type modifiers
> .\include\scoreboard.h(217) : see declaration of 'ap_update_child_status'
> Error executing cl.exe.
>
> Apache.exe - 1 error(s), 0 warning(s)
>
> --
> Jerry Baker
>
> PGP Key: http://keyserver.pgp.com/pks/lookup?op=get&search=0x48D96D45
>
> LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/
> Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
>
Re: 2.0.23?
Posted by Jerry Baker <je...@weirdness.com>.
Cliff Woolley wrote:
>
> In the meanwhile, I'd ask everyone to please give 2.0.23-dev a really good
> shakedown and let's try to make sure any lingering build errors are
> cleaned up. Sorry if this process has been tedious, but I want this beta
> to really shine.
Have been unable to build Apache today. Last successful build from CVS
was approximately 9am EDT. Build fails at libhttpd at service.c where
the MS compiler simply says:
registry.c
service.c
Generating Code...
Error executing xicl6.exe.
Apache.exe - 1 error(s), 1 warning(s)
xicl6 is a component of the Intel 4.5 C++ compiler that executes the
MS link.exe or the Intel linker depending. I have never had an issue
with it until today.
I tried uninstalling the Intel compiler which left me with:
--------------------Configuration: libhttpd - Win32 Release--------------------
Compiling...
scoreboard.c
D:\Apache\httpd-2.0\server\scoreboard.c(279) : error C2373: 'ap_update_child_status' : redefinition; different type modifiers
.\include\scoreboard.h(217) : see declaration of 'ap_update_child_status'
Error executing cl.exe.
Apache.exe - 1 error(s), 0 warning(s)
--
Jerry Baker
PGP Key: http://keyserver.pgp.com/pks/lookup?op=get&search=0x48D96D45
LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/
Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
Re: 2.0.23?
Posted by Greg Ames <gr...@remulak.net>.
"Paul J. Reder" wrote:
>
> Ok, I have run a cvs head build of 2.0.23 (as of Tuesday at 4:30) for 2.75
> hours with the following config and results. The synopsis is that it
> ran well until it died.
hope I do the same :-)
> Config:
> Server: (with a mirror of apache.org stored locally)
> Linux box with 384 MB of memory and 30 GB HD running threaded mpm with
> the apache.org httpd.conf with the following mpm config values.
> StartServers 3
> MaxClients 10
> MinSpareThreads 150
> MaxSpareThreads 300
> ThreadsPerChild 50
> MaxRequestsPerChild 3000
> Built with a copy of the config.nice from apache.org.
coool! daedalus has at least 1G of ram (running prefork on FreeBSD of
course)
> At about the 2.75 hour mark...
> ==================================================
> Current Time: Wednesday, 01-Aug-2001 10:48:54 EDT
> Restart Time: Wednesday, 01-Aug-2001 08:09:19 EDT
> Parent Server Generation: 0
> Server uptime: 2 hours 39 minutes 35 seconds
> Total accesses: 2259384 - Total Traffic: 63.1 GB
> CPU Usage: u31.79 s96.78 cu0 cs.06 - 1.34% CPU load
> 236 requests/sec - 6.8 MB/second - 29.3 kB/request
from daedalus, a few seconds ago:
46.8 requests/sec - 1.4 MB/second - 30.9 kB/request
So you're driving it about 5x harder than real life, on a box with less
than half the memory. waaay cool! Maybe this multithreaded MPM stuff
is a good idea after all ;-)
(of course, daedalus is doing other things besides serving http)
> The interesting portion of the error_log:
> [Wed Aug 01 10:07:59 2001] [notice] child pid 3102 exit signal Segmentation fault (11)
> [Wed Aug 01 10:46:39 2001] [alert] (12)Cannot allocate memory: apr_thread_create:
> unable to create worker thread
> [Wed Aug 01 10:46:39 2001] [alert] (12)Cannot allocate memory: apr_thread_create:
> unable to create worker thread
> [Wed Aug 01 10:46:39 2001] [alert] (12)Cannot allocate memory: apr_thread_create:
> unable to create worker thread
> [Wed Aug 01 10:46:49 2001] [alert] Child 19225 returned a Fatal error...
>
> At this point Apache stopped serving pages (duh). There was no core file (since
> Apache didn't dump it just exited). There were no core files from the segfaults either.
> I have received core files recently, but I can't pin my finger on why I do or
> don't get them.
I haven't gotten _any_ core dumps with threaded on Linux for ages; wish
I knew the answer.
btw, I assume you saw the patch Jeff just commited for a memory leak
with sockaddr stuff? don't know if it's applicable to you, but it might
be worth a try.
Does anyone know how to force a core dump on Linux? something like gcore
on FreeBSD? If we had a dump of a fat process (and Jeff's commit
doesn't take care of the memory leak), you could use the "x" command in
gdb to probe into the high end of the heap address range (the part that
doesn't exist in a skinny process), and see if you see any repeating
patterns.
Thanks,
Greg
Re: 2.0.23?
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
Ok, I have run a cvs head build of 2.0.23 (as of Tuesday at 4:30) for 2.75
hours with the following config and results. The synopsis is that it
ran well until it died.
Config:
Server: (with a mirror of apache.org stored locally)
Linux box with 384 MB of memory and 30 GB HD running threaded mpm with
the apache.org httpd.conf with the following mpm config values.
StartServers 3
MaxClients 10
MinSpareThreads 150
MaxSpareThreads 300
ThreadsPerChild 50
MaxRequestsPerChild 3000
Built with a copy of the config.nice from apache.org.
Clients, 18 copies of b running on 7 machines with the following parms:
./b -c 100 -n 120000 -f replay.list -v
where replay.list is an actual access_log from apache.org. All of these
machines have /etc/hosts files pointing all the apache.org urls at my
local server.
All machines are on a local ethernet switch with no other traffic. The server
is on a 100 Mbps connection. All connections are full duplex.
Results:______________________________________________________________________
There was a great deal of churning during the initial 10 minutes of the
abuse run. It would start a bunch of processes, but find there were too
many idle workers the next time around and kill some. Then the new workers
will have had a chance to catch requests and there were too few idle
workers the next time around... It eventually settled down with a pretty
steady average of about 300 workers and 100 processes (I checked ps -efH |
grep httpd | count_procs at regular intervals).
At the 1 hour mark...
==================================================
Current Time: Wednesday, 01-Aug-2001 09:09:15 EDT
Restart Time: Wednesday, 01-Aug-2001 08:09:19 EDT
Parent Server Generation: 0
Server uptime: 59 minutes 56 seconds
Total accesses: 1010248 - Total Traffic: 25.8 GB
CPU Usage: u22.56 s91.53 cu0 cs.01 - 3.17% CPU load
281 requests/sec - 7.3 MB/second - 26.8 kB/request
498 requests currently being processed, 1 idle workers
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
RWWWWWWWWRWWWWRWWWWWWWWWWWWWWWRRRWW.WWWWWWWWWWWRWWWWWWWWWRWWWWWW
WRWWRWWRWWWRWWWWWWWWWWRWWRRWWWWWRWWRWWWWWWWWWWWRWWWWWWRWWWWWWRWR
WWWWWWRWWRWWWWWWWWWWRWWWWWWWWWRWWWWWWWRWWWWWRWWWWWWWWWWWRWWRWWWW
WKWWWWWWWRRWWWWW_WWRRWRWWWWWWWWWWRWWWWRWWWWRWRWWWWWWWWWRWWWWWWWR
WWWWWWWRRWWWWWRWWWWWWRWWWWWRWWWWWRWWWRRWRWWWWWWWRWWWRWWWRWWRWWWW
WWWWWWWWWWWWWWRWWRWWWWWWWWWWWWWWWWWWWWWWWWWWWRWWWWRWRWWWWWWRWWRR
WWWWWRWWWWWWWWWWWRWWWWWWWWWWWWWWWWWWWWWWWWWWWRWWWWWW............
It started serving pages at a rate of about 350 rps and continued
to decrease throughout the first 1.25 hours until it had reached
a low value of about 195 rps. In part this decrease corresponded
to the occurance of large file requests until the average number
of concurrent large file requests had been reached. At this point
it seemed to reach a balanced state and began to rise slightly
over the next hour.
At the 2 hour mark...
==================================================
Current Time: Wednesday, 01-Aug-2001 10:09:24 EDT
Restart Time: Wednesday, 01-Aug-2001 08:09:19 EDT
Parent Server Generation: 0
Server uptime: 2 hours 5 seconds
Total accesses: 1532679 - Total Traffic: 48.3 GB
CPU Usage: u32.13 s44.79 cu.3 cs2.53 - 1.11% CPU load
213 requests/sec - 6.9 MB/second - 33.0 kB/request
324 requests currently being processed, 8 idle workers
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW.R.W.....R.WR.
.R.RWWRRWRWR..WW.RW.WWR...G...SWS...W_WWWWRWR.WRWRWRWR_SSGW..W.R
R.WW..RW....W..R......WRWSWWWWWWWWSWWW.W.WWWWWG...RWWRWW.WW....S
S.......W_WRWW__W_WW_SWSR.WRG.W...W.W.WRW.....W.......R...RRRRRR
WKWWWWRWRWWRRWWS_SWR.WRW.W.W.W.....W.....SS.WW.WRWWWRWWWWW.WWWWW
WRWWWWWWSW..W.......W..W.......WWWWWWWWWWWWRWWKSWWWS.WW....W...W
WW......WW.....WW.WW..WRWWWWWWRWRRWWWWRR.WWRW.WW.WWWWWWWWWWWWRRW
WRRWWSSWW.WGWW......WWW.WW..WW...W.....W..W.W.W.W...............
The server continued to slowly improve the rps value until it died.
The last status I caught was actually a couple of minutes after
the death of the main Apache. The kids continued serving pages for
a few minutes after Apache exited.
At about the 2.75 hour mark...
==================================================
Current Time: Wednesday, 01-Aug-2001 10:48:54 EDT
Restart Time: Wednesday, 01-Aug-2001 08:09:19 EDT
Parent Server Generation: 0
Server uptime: 2 hours 39 minutes 35 seconds
Total accesses: 2259384 - Total Traffic: 63.1 GB
CPU Usage: u31.79 s96.78 cu0 cs.06 - 1.34% CPU load
236 requests/sec - 6.8 MB/second - 29.3 kB/request
190 requests currently being processed, 0 idle workers
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW.WWW..WW.WWW
W.WWG..WW..W.....WWW.WWW.WW.W..W....._.....R.W.W.WWW...WW.WWWW..
....W.WW.WW.W.G....W..W.W.RR.WWWW.WR..WW.WWWWWW.WRWWWWSW..GW....
........WW..W.R..WWW..W.WWW.W..W.WW.WW.WW..WWW..WWWWWWS.....WW.W
WK.W.W.W..WW.W.._..R.WR.WW.WG.WW.W.WW..WW.W...W.W...WWW..WW.W.WW
W.W.W..W...W..R..W....W.G....WRW.RR...WWW..WW.WWWWRWW....WWR.WWW
W..WW.WWRRWW.WS.WWRRWWWWRRRWWWRWWWRRWWWWWRWWRWWWWRRWRRWRWRWWWWWW
WW...W.W.W..WW..WWGWW.WWWWWW.W.WW..WWW..W....W..W.W.............
About 3 minutes after this, Apache stopped serving pages.
The interesting portion of the error_log:
-----------------------------------------
[Wed Aug 01 08:10:23 2001] [error] server reached MaxClients setting,
consider raising the MaxClients setting
[Wed Aug 01 08:15:28 2001] [notice] child pid 5846 exit signal Segmentation fault (11)
[Wed Aug 01 08:15:41 2001] [notice] child pid 6157 exit signal Segmentation fault (11)
[Wed Aug 01 08:27:09 2001] [notice] child pid 14585 exit signal Segmentation fault (11)
[Wed Aug 01 08:29:11 2001] [notice] child pid 15484 exit signal Segmentation fault (11)
[Wed Aug 01 09:51:11 2001] [notice] child pid 27771 exit signal Segmentation fault (11)
[Wed Aug 01 10:01:39 2001] [notice] child pid 31783 exit signal Segmentation fault (11)
[Wed Aug 01 10:05:42 2001] [notice] child pid 1529 exit signal Segmentation fault (11)
[Wed Aug 01 10:07:59 2001] [notice] child pid 3102 exit signal Segmentation fault (11)
[Wed Aug 01 10:46:39 2001] [alert] (12)Cannot allocate memory: apr_thread_create:
unable to create worker thread
[Wed Aug 01 10:46:39 2001] [alert] (12)Cannot allocate memory: apr_thread_create:
unable to create worker thread
[Wed Aug 01 10:46:39 2001] [alert] (12)Cannot allocate memory: apr_thread_create:
unable to create worker thread
[Wed Aug 01 10:46:49 2001] [alert] Child 19225 returned a Fatal error...
At this point Apache stopped serving pages (duh). There was no core file (since
Apache didn't dump it just exited). There were no core files from the segfaults either.
I have received core files recently, but I can't pin my finger on why I do or
don't get them.
--
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: 2.0.23?
Posted by David Reid <dr...@jetnet.co.uk>.
> From: "Cliff Woolley" <cl...@yahoo.com>
> Sent: Wednesday, August 01, 2001 12:14 AM
>
>
> > On Tue, 31 Jul 2001, William A. Rowe, Jr. wrote:
> >
> > > > also happens without either. i just hit this in the modperl 'make
> > > > test' after syncing. its related to this change:
> > > >
> > > > cvs diff -r1.333 -r1.334 modules/http/http_protocol.c
> > > >
> > > > after backing it out (not committed yet) things are working again.
> > >
> > > Yup. My bad. I've backed it out. Thank you for finding this!
> >
> > This is yet another problem with 2.0.22, and a rather troublesome one at
> > that. Thanks for the research, guys. Good work.
> >
> > There are enough things wrong with 2.0.22 that are already fixed that
I'm
> > going to go ahead and tag 2.0.23 first thing Thursday morning as I
> > suggested in my State of the beta email. If it turns out to be
obviously
> > better than 2.0.22, which I believe it will, then we'll go with 2.0.23
> > instead. Of course, we still technically have a "go ahead" vote for
> > 2.0.22 as a beta... we'll kind of have a tarball death match to see
which
> > one wins more support as a beta. =-)
>
> Cool :)
>
> > In the meanwhile, I'd ask everyone to please give 2.0.23-dev a really
good
> > shakedown and let's try to make sure any lingering build errors are
> > cleaned up. Sorry if this process has been tedious, but I want this
beta
> > to really shine.
>
> Is 15 hrs a day enough :-?
>
> > PS: Fixes for the Mac OS X/Darwin problem have still not been committed.
> > It was two problems... one of which was the version of buildconf on
> > icarus, no doubt (hence the old config.guess in the tarball). I'll see
> > what I can do about that. The other problem probably just needs a
> > configure check added or maybe some hints magic... can someone with a
> > Darwin box please do me a favor and fix this the right way, please?
>
> I would really really like to see that fixed, if we go to the trouble of
> dumping 2.0.22. There was also that one question about the linux build,
> as well, and David's apu_dbm headaches.
The problems with apu_dbm were due to file locking... As to how I fix them
I don't know yet...
david
Re: 2.0.23?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Cliff Woolley" <cl...@yahoo.com>
Sent: Wednesday, August 01, 2001 12:14 AM
> On Tue, 31 Jul 2001, William A. Rowe, Jr. wrote:
>
> > > also happens without either. i just hit this in the modperl 'make
> > > test' after syncing. its related to this change:
> > >
> > > cvs diff -r1.333 -r1.334 modules/http/http_protocol.c
> > >
> > > after backing it out (not committed yet) things are working again.
> >
> > Yup. My bad. I've backed it out. Thank you for finding this!
>
> This is yet another problem with 2.0.22, and a rather troublesome one at
> that. Thanks for the research, guys. Good work.
>
> There are enough things wrong with 2.0.22 that are already fixed that I'm
> going to go ahead and tag 2.0.23 first thing Thursday morning as I
> suggested in my State of the beta email. If it turns out to be obviously
> better than 2.0.22, which I believe it will, then we'll go with 2.0.23
> instead. Of course, we still technically have a "go ahead" vote for
> 2.0.22 as a beta... we'll kind of have a tarball death match to see which
> one wins more support as a beta. =-)
Cool :)
> In the meanwhile, I'd ask everyone to please give 2.0.23-dev a really good
> shakedown and let's try to make sure any lingering build errors are
> cleaned up. Sorry if this process has been tedious, but I want this beta
> to really shine.
Is 15 hrs a day enough :-?
> PS: Fixes for the Mac OS X/Darwin problem have still not been committed.
> It was two problems... one of which was the version of buildconf on
> icarus, no doubt (hence the old config.guess in the tarball). I'll see
> what I can do about that. The other problem probably just needs a
> configure check added or maybe some hints magic... can someone with a
> Darwin box please do me a favor and fix this the right way, please?
I would really really like to see that fixed, if we go to the trouble of
dumping 2.0.22. There was also that one question about the linux build,
as well, and David's apu_dbm headaches.
Bill
2.0.23?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Tue, 31 Jul 2001, William A. Rowe, Jr. wrote:
> > also happens without either. i just hit this in the modperl 'make
> > test' after syncing. its related to this change:
> >
> > cvs diff -r1.333 -r1.334 modules/http/http_protocol.c
> >
> > after backing it out (not committed yet) things are working again.
>
> Yup. My bad. I've backed it out. Thank you for finding this!
This is yet another problem with 2.0.22, and a rather troublesome one at
that. Thanks for the research, guys. Good work.
There are enough things wrong with 2.0.22 that are already fixed that I'm
going to go ahead and tag 2.0.23 first thing Thursday morning as I
suggested in my State of the beta email. If it turns out to be obviously
better than 2.0.22, which I believe it will, then we'll go with 2.0.23
instead. Of course, we still technically have a "go ahead" vote for
2.0.22 as a beta... we'll kind of have a tarball death match to see which
one wins more support as a beta. =-)
In the meanwhile, I'd ask everyone to please give 2.0.23-dev a really good
shakedown and let's try to make sure any lingering build errors are
cleaned up. Sorry if this process has been tedious, but I want this beta
to really shine.
PS: Fixes for the Mac OS X/Darwin problem have still not been committed.
It was two problems... one of which was the version of buildconf on
icarus, no doubt (hence the old config.guess in the tarball). I'll see
what I can do about that. The other problem probably just needs a
configure check added or maybe some hints magic... can someone with a
Darwin box please do me a favor and fix this the right way, please?
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: mod_tls and HTTP POST
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Doug MacEachern" <do...@covalent.net>
Sent: Tuesday, July 31, 2001 9:57 PM
> On Tue, 31 Jul 2001, William A. Rowe, Jr. wrote:
>
> > FYI, this also affects mod_ssl.
>
> also happens without either. i just hit this in the modperl 'make
> test' after syncing. its related to this change:
>
> cvs diff -r1.333 -r1.334 modules/http/http_protocol.c
>
> after backing it out (not committed yet) things are working again.
Yup. My bad. I've backed it out. Thank you for finding this!
Bill
Re: mod_tls and HTTP POST
Posted by Doug MacEachern <do...@covalent.net>.
On Tue, 31 Jul 2001, William A. Rowe, Jr. wrote:
> FYI, this also affects mod_ssl.
also happens without either. i just hit this in the modperl 'make
test' after syncing. its related to this change:
cvs diff -r1.333 -r1.334 modules/http/http_protocol.c
after backing it out (not committed yet) things are working again.
Re: mod_tls and HTTP POST
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Jerry Baker" <je...@weirdness.com>
Sent: Tuesday, July 31, 2001 4:00 PM
> Apache 2.0.23-dev (from CVS yesterday) with OpenSSL 0.9.6b.
>
> If mod_tls is being used, a POST operation where $ENV{"Content-Length"}
> exceeds 570 fails. That is to say that there is nothing sent to STDIN.
> This was tried with IE 5.5, Netscape 4.78, and Mozilla 0.9.2.
FYI, this also affects mod_ssl.
Re: mod_tls and HTTP POST
Posted by Jerry Baker <je...@weirdness.com>.
"William A. Rowe, Jr." wrote:
>
> I've narrowed this (already noted to Jerry) to something in the filter stack.
>
> You can demonstrate it by simply trying manual/misc/FAQ.html with SSI enabled.
> The SSI includes are dropped. There may be further complications in the
> interaction of the http_core.c and core.c filters, I'm still looking at that.
>
> Bill
Dunno if it's related, but submitting a form with a lot of data (eg, 9k
or so) takes a *very* long time compared with 1.3.20 - even when done
over regular http.
--
Jerry Baker
PGP Key: http://keyserver.pgp.com/pks/lookup?op=get&search=0x48D96D45
LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/
Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
Re: mod_tls and HTTP POST
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
I've narrowed this (already noted to Jerry) to something in the filter stack.
You can demonstrate it by simply trying manual/misc/FAQ.html with SSI enabled.
The SSI includes are dropped. There may be further complications in the
interaction of the http_core.c and core.c filters, I'm still looking at that.
Bill
----- Original Message -----
From: "Jerry Baker" <je...@weirdness.com>
To: <ne...@apache.org>
Sent: Tuesday, July 31, 2001 4:00 PM
Subject: mod_tls and HTTP POST
> Apache 2.0.23-dev (from CVS yesterday) with OpenSSL 0.9.6b.
>
> If mod_tls is being used, a POST operation where $ENV{"Content-Length"}
> exceeds 570 fails. That is to say that there is nothing sent to STDIN.
> This was tried with IE 5.5, Netscape 4.78, and Mozilla 0.9.2.
>
> To test this I set up a form with a single "textarea" and had it "POST"
> to a Perl script that simply read STDIN into a scalar ($variable) and
> then did a "print $variable". It works fine as long as the content
> length < 570. If the content length > 570 then Perl reports $variable as
> undefined. If I access the same form without TLS (eg, http instead of
> https) then it works fine.
>
> Another oddity with TLS is that with TLS active, accessing the stock
> printenv.pl that ships with Apache fails. When accessed via https the
> output of that script is truncated.
>
> PS - I am not subscribed to new-httpd because as of the sending of this
> message all messages sent to new-httpd-subscribe@apache.org have gone
> unanswered.
>
> --
> Jerry Baker
>
> PGP Key: http://keyserver.pgp.com/pks/lookup?op=get&search=0x48D96D45
>
> LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/
> Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
>