ID: 31558
Updated by: [EMAIL PROTECTED]
Reported By: jdw at nearlyfreespeech dot net
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: FreeBSD
PHP Version: 4.3.10
New Comment:
Disable PHP from Apache and see if the problem persists. It is possible
that one the libraries used by PHP is leaking etc... Right now all we
know is that your PHP is failing to allocate memory and you are
claiming that PHP leaks. Well, that does not say a whole lot.
Previous Comments:
------------------------------------------------------------------------
[2005-01-20 23:41:47] jdw at nearlyfreespeech dot net
As previously indicated, the system limits are not in play. Or rather,
if they are, they shouldn't be. I've said that a couple of times now in
attempt to avoid a quick "you're out of memory" reaction.
Unfortunately, that strategy does not appear to be a winner.
The per-process allocation limits are currently set to 512M.
That is a very savvy observation that the process size grows to 512M
and then allocations fail. I checked out the size of the core dump
file, and it confirms your theory. Whatever random PHP script, large
or small, is running at that point gets hosed (obviously). Good
catch!
But it is a little hasty to jump from that to "bogus."
The "steady state" size of Apache processes on this system should be
about 30M. Where did the other 480M come from?
Further research today has shown that Apache leaks about 1mb of RAM on
every "graceful" (SIGUSR1) restart. If it's something else leaking,
fine, but so far the stack trace says it's PHP.
Perhaps instead of rushing to "bogus," you could suggest some ways I
could prove or disprove the theory that PHP leaks memory when Apache is
reconfigured.
That would be very helpful, and I would very much appreciate help from
any corner with this problem.
(State changed to "open." If investigation reveals that the leak is
not in PHP I'll be the first one to change it to bogus.)
Thanks!
------------------------------------------------------------------------
[2005-01-20 22:37:42] [EMAIL PROTECTED]
Sounds like your system may have a limit on the amount of memory a
single process can request. When that limit is reached and php fails to
allocate memory it terminates with an error that you are seeing.
------------------------------------------------------------------------
[2005-01-20 14:11:33] jdw at nearlyfreespeech dot net
A very large number of them this morning:
FATAL: erealloc(): Unable to allocate 61440 bytes
2 FATAL: erealloc(): Unable to allocate 983040 bytes
FATAL: erealloc(): Unable to allocate 61440 bytes
4 FATAL: erealloc(): Unable to allocate 983040 bytes
FATAL: erealloc(): Unable to allocate 61440 bytes
9 FATAL: erealloc(): Unable to allocate 983040 bytes
FATAL: erealloc(): Unable to allocate 61440 bytes
FATAL: erealloc(): Unable to allocate 983040 bytes
To reproduce this, I believe it is important to have apache do a
graceful restart a few hundred times. Could the leak be in parsing PHP
config variables out of httpd.conf?
Here's a stack trace:
#0 0x28178a62 in memcpy () from /usr/lib/libc.so.4
#1 0xbfbf948c in ?? ()
#2 0x283702b1 in php_apache_admin_value_handler (cmd=0xbfbf9460,
conf=0x280c7d80, arg1=0x8b1e3cc "max_execution_time",
arg2=0x8b1e3e4 "180")
at
/tmp/source/php_apache_debug/php4-STABLE-200501171730/sapi/apache/mod_php4.c:780
#3 0x08074f58 in invoke_cmd (cmd=0x285406b0, parms=0xbfbf9460,
mconfig=0x280c7d80, args=0xbfbf52c6 "") at http_config.c:826
#4 0x08075872 in ap_handle_command (parms=0xbfbf9460,
config=0x85885c4,
l=0xbfbf52a0 "php_admin_value max_execution_time 180")
at http_config.c:1037
#5 0x080758f9 in ap_srm_command_loop (parms=0xbfbf9460,
config=0x85885c4)
at http_config.c:1051
#6 0x08079c86 in virtualhost_section (cmd=0xbfbf9460, dummy=0x80d79cc,
arg=0xbfbf73cd "*") at http_core.c:1972
#7 0x08074dd2 in invoke_cmd (cmd=0x80bc700, parms=0xbfbf9460,
mconfig=0x80d79cc, args=0xbfbf73cd "*") at http_config.c:796
#8 0x08075872 in ap_handle_command (parms=0xbfbf9460,
config=0x80d6d84,
l=0xbfbf73c0 "<VirtualHost *") at http_config.c:1037
#9 0x080758f9 in ap_srm_command_loop (parms=0xbfbf9460,
config=0x80d6d84)
at http_config.c:1051
#10 0x0807607c in ap_process_resource_config (s=0x80d6034,
fname=0x8588314 "/nfsn/apps/apache/vhosts/ninjaman.conf",
p=0x80d600c,
---Type <return> to continue, or q <return> to quit---
ptemp=0xca8b00c) at http_config.c:1343
#11 0x0807b0b8 in include_config (cmd=0xbfbfb650, dummy=0x80d79cc,
name=0x8588314 "/nfsn/apps/apache/vhosts/ninjaman.conf")
at http_core.c:2769
#12 0x08074ea8 in invoke_cmd (cmd=0x80bcdf0, parms=0xbfbfb650,
mconfig=0x80d79cc, args=0xbfbf95de "") at http_config.c:814
#13 0x08075872 in ap_handle_command (parms=0xbfbfb650,
config=0x80d6d84,
l=0xbfbf95b0 "Include /nfsn/apps/apache/vhosts/ninjaman.conf")
at http_config.c:1037
#14 0x080758f9 in ap_srm_command_loop (parms=0xbfbfb650,
config=0x80d6d84)
at http_config.c:1051
#15 0x0807607c in ap_process_resource_config (s=0x80d6034,
fname=0x19d831e4 "/nfsn/apps/apache/conf/vhosts.conf", p=0x80d600c,
ptemp=0xca8b00c) at http_config.c:1343
#16 0x0807b0b8 in include_config (cmd=0xbfbfd840, dummy=0x80d79cc,
name=0x19d831e4 "/nfsn/apps/apache/conf/vhosts.conf") at
http_core.c:2769
#17 0x08074ea8 in invoke_cmd (cmd=0x80bcdf0, parms=0xbfbfd840,
mconfig=0x80d79cc, args=0xbfbfb7b8 "") at http_config.c:814
#18 0x08075872 in ap_handle_command (parms=0xbfbfd840,
config=0x80d6d84,
l=0xbfbfb7a0 "include conf/vhosts.conf") at http_config.c:1037
#19 0x080758f9 in ap_srm_command_loop (parms=0xbfbfd840,
config=0x80d6d84)
at http_config.c:1051
#20 0x0807607c in ap_process_resource_config (s=0x80d6034,
---Type <return> to continue, or q <return> to quit---
fname=0xb5bb28c "/nfsn/apps/apache/conf/cluster.conf", p=0x80d600c,
ptemp=0xca8b00c) at http_config.c:1343
#21 0x0807b0b8 in include_config (cmd=0xbfbffa30, dummy=0x80d79cc,
name=0xb5bb28c "/nfsn/apps/apache/conf/cluster.conf") at
http_core.c:2769
#22 0x08074ea8 in invoke_cmd (cmd=0x80bcdf0, parms=0xbfbffa30,
mconfig=0x80d79cc, args=0xbfbfd9a9 "") at http_config.c:814
#23 0x08075872 in ap_handle_command (parms=0xbfbffa30,
config=0x80d6d84,
l=0xbfbfd990 "Include conf/cluster.conf") at http_config.c:1037
#24 0x080758f9 in ap_srm_command_loop (parms=0xbfbffa30,
config=0x80d6d84)
at http_config.c:1051
#25 0x0807607c in ap_process_resource_config (s=0x80d6034,
fname=0x80cbaa0 "/nfsn/conf/httpd.conf", p=0x80d600c,
ptemp=0xca8b00c)
at http_config.c:1343
#26 0x0807697c in ap_read_config (p=0x80d600c, ptemp=0xca8b00c,
confname=0x80cbaa0 "/nfsn/conf/httpd.conf") at http_config.c:1635
#27 0x08080fb5 in standalone_main (argc=1, argv=0xbfbffbb4) at
http_main.c:5373
#28 0x080818fe in main (argc=1, argv=0xbfbffbb4) at http_main.c:5767
#29 0x0804fc26 in _start ()
(gdb)
------------------------------------------------------------------------
[2005-01-20 08:16:02] [EMAIL PROTECTED]
You can ignore the strtotime() test failing, that is a bug on FreeBSD.
------------------------------------------------------------------------
[2005-01-20 07:22:16] jdw at nearlyfreespeech dot net
I enabled memory limits during the rebuild, and we've already gotten
one of these:
Allowed memory size of 8388608 bytes exhausted at
/tmp/source/php_apache_debug/php4-STABLE-200501171730/main/output.c:230
(tried to allocate 12 bytes)
I don't have enough info to know if this is related or just
coincidence. Is there any way to tell what request it was?
(I want to reiterate that our error happens at random on simple pages
that cannot possibly take up 8mbs of RAM to render, lest anyone see
this and say "oh they really are out of RAM after all" and close the
bug.)
I can change or remove the memory limit if you think this might mask
the real problem.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/31558
--
Edit this bug report at http://bugs.php.net/?id=31558&edit=1
