I'm sorry but the problem described in bug 11997 is still here...
And child process fails to exit and stays in memory.

I'm having the same problem on my Win2k server (fully patched/updated) - 2x
Intel Xeon. I have Apache 2.0.55 (with openSSL 0.9.8a), PHP 5.1.2. 

The log entry:
[Thu Feb 23 09:28:12 2006] [warn] (OS 64)The specified network name is no longer
available.  : winnt_accept: Asynchronous AcceptEx failed.

was not present while we were using a Symantec Enterprise Firewall, but were
introduced when we switched to Cisco Pix 515e Firewall (appliance). I got rid of
such log entries with Win32DisableAcceptEx in the httpd.conf, but this caused
the following errors about every 10-20 minutes:

FATAL:  erealloc():  Unable to allocate 393216 bytes
[Thu Feb 23 10:15:58 2006] [notice] Parent: child process exited with status 1
-- Restarting.

I see that memory consumption by apache is increasing, and number of threads
too, until it restarts itself.

If I remove the Win32DisableAcceptEx, the server is "very" slow in handling
requests and of course the error.log is getting all those entries I quoted first.
But as I said, this started after we installed the Cisco FW, and we have placed
a bug-thing with Cisco as well.

I have the same problem on Win2K servers, PHP 4.3.11.

The erealloc/emalloc fatals occurs when I put Win32DisableAcceptEx config
directive in httpd.conf. When I comment it, no more erealloc/emalloc occurs in
the logs, but the warnings described above.

So it seems to be a memory leak when using the old Accept primitive or something...

(In reply to comment #2)

This problem is "increasing", meaning it cause a big problem. The line:

FATAL:  erealloc():  Unable to allocate 1572864 bytes

with the exact same number of bytes each time, is appearing every 10-15 minutes
now, and after a day or two apache stops responding (web pages will not load). A
restart of the service will not fix it, I need to restart the entire server.

I have the following now:

(win2k server still (2 cpu))

Apache 2.0.59
OpenSSL 0.9.8c
PHP 5.1.6

Exact same issue here. Apache restarts (stopping all transfers & active
connections) after consuming a lot of RAM memory (up to peaks of 100-200MB).

Apache 2.2.3
WinXP 1GBRAM Pentium M 1,4GHz
Happens when Firewall disabled.

Hope to see a bugfix soon.
Phil

FYI this is known-of on 2.0.59 as well, and in the process of researching.

Can you reporters confirm if you are or are not proxying traffic, and if
that's using ssl from the client and/or ssl to the backend?

Or if you are simply using ssl or not for client (non-proxy) traffic?

(In reply to comment #6)
> FYI this is known-of on 2.0.59 as well, and in the process of researching.
> Can you reporters confirm if you are or are not proxying traffic, and if
> that's using ssl from the client and/or ssl to the backend?
> Or if you are simply using ssl or not for client (non-proxy) traffic?

We are not proxying traffic, and are simply using ssl for client traffic. Note 
that this issue is only valid when Win32DisableAcceptEx is enabled 
(uncommented) in the conf. I have not tried this with PHP 5.2 which has been 
released, to see if that has something to do with it

One more note - we -don't- call erealloc from apr 0.9 or httpd 2.0.

So something else is going on here, either in PHP or in the msvcrt, or perhaps
because of crossed up msvc versions.

FYI there's a bugreport at php.net regarding this, although I don't think it's 
anything new there: http://bugs.php.net/bug.php?id=32002

I will try to install PHP 5.2 after the weekend and will let you know if it 
helps in any way. I understand that there's some changes to memoryhandling or 
something there....

Well if you can determine that this happens with PHP compiled with Visual C 6.0,
linked using /MD (multithread dll c runtime) or only Visual C > 6.0, we might be
on to something.

It's a question of if this is a PHP bug, or a memory management flaw resulting
from the c runtimes in use.

I have not used SSL or mod_proxy at the time of this report.
It was very simple configuration for a few vhosts with PHP (as module) ans SSI.

Now we've changed the platform to Linux, so I can do no more tests... 

I have now installed PHP 5.2 on the server (regular downloaded from php.net),
and the issue seems to be gone. No fatal errors for 24 hours, but I will let you
know if it happens again during peek traffic (although it came every 10-15
minutes no matter what traffic we had).

Well, the fatal is still gone, but Apache seems to leak memory. It starts with a
few MB, but is up in 4-500 MB "shortly". 

From my conf:
<IfModule mpm_winnt.c>
ThreadsPerChild 200
MaxRequestsPerChild  0
</IfModule>
EnableMMAP off
Win32DisableAcceptEx
EnableSendfile off

I have removed Win32DisableAcceptEx, and the memory consumption does not
increase. But then I'm back to "The specified network name is no longer
available.  : winnt_accept: Asynchronous AcceptEx failed." in the log. Last time
I did this it also served pages really slow, but now it seems to do this faster.
So, I think I will leave it like this and just purge the error log once in a
while. Or degrade to PHP 5.1.6 to have apache restart itself :)

Hello everyone,

I'd like to report that this particular bug is affecting us as well. We have two
identical web servers running (using load balancing):
Dell, Win2003 Web Edition, 2.8 Ghz, 2 GB memory
Apache 2.2.3, OpenSSL 0.9.8d
Tomcat 5.5.17
PHP 5.2, Zend Optimizer 3

We used to run IIS for over 4 years, but we've always had problems with the
IIS->Tomcat integration. This September we switched to Apache and also started
using PHP.

I had to apply the "Win32DisableAcceptEx / EnableMMAP off / EnableSendfile off"
trio, without it, same errors as mentioned above kept appearing in the error
log, and the users got Page Not Found errors. After applying these settings,
everything seemed fine. There's no firewall software running, but there is a
Sonicwall firewall on the network.

After applying Win32DisableAcceptEx, then "FATAL:  erealloc():  Unable to
allocate XXX bytes" lines immediately started appearing. I did a lot of
searching, assuming the problem was with PHP. (5.1.6 did the same thing. We have
some pages that are encoded, so we needed the new Zend Optimizer too before we
could upgrade to 5.2. It's now out, we upgraded, same problem.)

I wrote a small program to monitor and log the memory taken up by httpd.exe, and
I found that it restarted itself about every 4-5 hours, when it reached around
440Mb. Then I finally found this thread, and the suggestion of the original
poster worked. "ThreadsPerChild" was 250 in httpd.conf, I reduced that to 120,
and it was fine. The service was 100% up! However, our sites became slow, we're
getting about 100 requests per second. We tried to increase the number of
threads. With 150 it still died every 4-5 hours. With 135 too. Now it's on 128,
and it's been stable for almost a day. That's way too low however, the servers
should be able to handle a lot more than that.

I understand that this problem will be very hard to track down and fix... I'm
still not even 100% convinced that it's an Apache problem, could be PHP. Still I
hope someone will be able to figure this out and put out a fix.

Hi all,

Oh, how I hope someone can give us a clue on what to do with this. Here's what
we've been doing to try to isolate the problem.

1) We thought SSL might be the problem, so we took it out of the equation by
setting up a new web server to take all the SSL connection, and reconfigured
Apache on our production servers to only listen on port 80. No noticeable
changes or improvement.

2) We purchased a shiny new web server from Dell. Quad core CPU (2.33 Ghz), 4 GB
RAM. Very fast, and should be more than adequate for a simple web server. Same
configuration as our other servers. Apache (or PHP, we still don't know which)
dies just as happily:

Fatal error: Out of memory (allocated 0) (tried to allocate 2 bytes) in Unknown
on line 0
[Mon Mar 05 02:44:04 2007] [notice] Parent: child process exited with status
4294967295 -- Restarting.

We watched the server closely, and when these errors happen, the CPU is low, the
number of active connections is low, and there's over 2 GB of physical memory
available. It's running out of *SOMETHING*, we just don't know what. It always,
very reliably runs out of this something. The higher the threads, the faster (it
seems).

But, at least we had 3 servers serving up 128 threads each, which was
temporarily acceptable.

3) We are running 7 websites, only one of which uses PHP. So we directed the 6
websites to just one server and we opened up the threads to 512, and that
machine has been running without a hitch ever since. So it's just Apache +
Tomcat. Hooray! Go Apache! This points to the problem definitely being in PHP,
or the integration of PHP + Apache. (Please, don't send us away to go and post
it on the PHP bug list just yet... All they are going to do is mark it as bogus.)

4) We updated to Apache 2.2.4. No noticeable difference unfortunately.

The problem is, the traffic on the one site that uses PHP is steadily
increasing. (It feels weird calling this a problem :-)) We upgraded our staging
server to 2 GB of RAM, so it's the same specs as the others, and now 3
production servers are serving up just that one site. In addition we restart
Apache daily. It worked fine for a while, but now it's getting worse: even with
just serving 128 threads, and restarting the whole service daily (we have the
redundancy for it), the above error is starting to present itself more and more
frequently...

I didn't mention yet that we tried for over a week to reliably reproduce this
problem on our staging server, but we simply cannot. Our conclusion was that
it's because when we send load to it (much bigger loads than what we normally
get on production), it's all coming from the same IP. Whereas normal traffic
comes from all over the place, different IPs, different browsers.

We've looked at this so much already and running out of ideas and options. Help
please?

closing this as a php bug.

http://httpd.apache.org/dev/debugging.html

gives information on how to get an ENTIRE backtrace.