Bug 88727 - unlimited memory consumption
Summary: unlimited memory consumption
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: php
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-12 17:26 UTC by Adrian Reber
Modified: 2007-04-18 16:53 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-04-14 09:19:13 UTC

Attachments (Terms of Use)

Description Adrian Reber 2003-04-12 17:26:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030327

Description of problem:
This problem does not happen with httpd-2.0.40-21 only with the update

It is not very easy to describe this problem.
After starting the new httpd one of the httpd processes
starts allocating lot of memory. The first time it took
httpd about 2 days to come to this state. The second time
18 hours and after another restart it was there after 15 minutes.

I was observing the processes with top and had it sort
by memory usage. The normal situation is to have one apache 
process with 115MB and lot of other processes with 8MB.

But then one or two processes of httpd jump to the top of the 
list and have memory usage between 500MB and 1.5 GB.

Strange thing is, that they don't stay at the top but disappear
again and come back again with different memory usage. 
The changes of the used memory are rather big. One moment 200MB and 
next 800MB.
Sometimesmore sometimes less. But the overall trend is that these processes use
more and more memory until the computer does not react anymore. After 10 or 20
minutes everthing is okay again and in dmesg following can be read:

Out of Memory: Killed process 12763 (httpd).

This server is running a updated redhat 9 from redhat 8.
The kernel is not a redhat kernel but selfmade with no patches
except the ptrace exploit fix. kernel is 2.4.20

In the logfiles there is no hint would happened. In the error_log
following can be seen:

child pid 26492 exit signal Segmentation fault (11)

But I think this happens after the kernel killed the httpd process.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. start httpd
2. wait
3. kernel kills one of the httpd process

Additional info:

Comment 1 Adrian Reber 2003-04-12 17:47:19 UTC

This is not a bug, but a bad written php script.

At least that's what I am thinking now.

Comment 2 Joe Orton 2003-04-14 08:25:18 UTC
If you have in /etc/php.ini:

memory_limit = 8M

(per the default) a PHP script shouldn't (in theory) be able to consume large
amounts of RAM.

Can you track down what script is causing the error, and check whether your
memory_limit is set?

Comment 3 Adrian Reber 2003-04-14 08:47:06 UTC
The memory limit is set but it doesn't help. It was set and the default
was not changed.

I am not 100% sure but I think the script producing the error is at:


I am mirroring the ecplise project (www.eclipse.org) and this script
comes from there. The problem is that the script tries to access files
which are I do not mirror and therefore can not be accessed. That's why
the script is probably failing. As soon as I rename the file back to .php
and try to access it the same error happens again with apache.

Comment 4 Joe Orton 2003-04-14 09:05:18 UTC
Yeah, it is a script bug, I don't know why it would act differently under a
different version of httpd though.  Change:

-       while (!feof($fileHandle)) {
+       while ($filehandle && !feof($fileHandle)) {

Comment 5 Adrian Reber 2003-04-14 09:12:52 UTC
Sorry. I forgot to mention that it acts the same no matter which httpd
version I was using.
The update and the script just came roughly at the same time, so I first
blamed the update of httpd.
Thanks for the fix. I will forward it to the upstream authors.

Comment 6 Joe Orton 2003-04-14 09:19:13 UTC
OK, great.  I'll close this as NOTABUG then, though you might want to file a bug
at bugs.php.net that this script fragment will consume all memory.

Note You need to log in before you can comment on or make changes to this bug.