You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Cliff Woolley <cl...@yahoo.com> on 2001/08/01 07:14:54 UTC
2.0.23?
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: 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 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
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/