Bug 88727
| Summary: | unlimited memory consumption | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Adrian Reber <adrian> |
| Component: | php | Assignee: | Joe Orton <jorton> |
| Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-04-14 09:19:13 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Sorry. This is not a bug, but a bad written php script. At least that's what I am thinking now. 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? 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: http://ftp-stud.fht-esslingen.de/pub/test/testResults.php.txt 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. 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)) {
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. 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. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4 Description of problem: This problem does not happen with httpd-2.0.40-21 only with the update httpd-2.0.40-21.1 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): httpd-2.0.40-21.1 How reproducible: Sometimes Steps to Reproduce: 1. start httpd 2. wait 3. kernel kills one of the httpd process Additional info: