ID: 31558
User updated by: jdw at nearlyfreespeech dot net
Reported By: jdw at nearlyfreespeech dot net
Status: Open
Bug Type: Reproducible crash
Operating System: FreeBSD
PHP Version: 4.3.10
New Comment:
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)
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2005-01-20 07:04:35] jdw at nearlyfreespeech dot net
We have put the -stable code into place on part of our network. We'll
see what happens.
I observed the following in "make test."
=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
pspell basic tests (warning: may fail with pspell/aspell < GNU Aspell
0.50.3) [e
xt/pspell/tests/01pspell_basic.phpt]
Bug #31213 (Sideeffects caused by bug #29493)
[ext/standard/tests/array/bug31213.phpt]
Bug #30069 (floats as strings used in calculations do not work)
[ext/standard/tests/math/bug30069.phpt]
Bug #27780 (strtotime(+1 xxx) returns a wrong date/time)
[ext/standard/tests/time/bug27780.phpt]
=====================================================================
Of these, only the last one also fails on identical hardware /config
under 4.3.10. If this matters for a "LATEST" release, I'll report it
separately; not sure of the protocol there. Otherwise, I'll report
back when we see the problem again.
------------------------------------------------------------------------
[2005-01-15 00:16:00] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
First get the stable snapshot.
Configure with --enable-debug (that will actually make PHP more stable
in some cases..)
Then see if you get any weird leaks or something in your logs.
And/or crashes -> generate a GDB backtrace and paste it here.
------------------------------------------------------------------------
[2005-01-14 23:47:03] jdw at nearlyfreespeech dot net
Our PHP config is at:
http://example.nfshost.com/phpinfo.php
If you need anything beyond that, let me know what, and I'll add it
here. I'll put the php.ini at the bottom, along with example per-site
overrides.
It's pretty stock. They only Zend module I've heard of is the
optimizer, and I know we don't use that. The config line is at the top
of the phpinfo page.
strace does not appear on these FreeBSD boxes and 'httpd -?' does not
show -X as an option, so I may need some guidance as to what you're
hoping to accomplish with that to find the equivalent. If strace is
like ktrace, then I have to assume that the output generated by the
parent and all child processes would be problematically large.
>From the source code, it looks like we can define a flag that will SEGV
the httpd when this occurs. Is it possible that this would generate a
useful backtrace? Would defining this flag (ZEND_DEBUG, I think) have
other dreadful consequences not consistent with running in production?
Thanks for looking at this!
php.ini:
auto_prepend_file = nfsn_umask_hack.php
upload_tmp_dir = /tmp
max_execution_time = 180
browscap = /nfsn/apps/php/lib/browscap.ini
post_max_size = 10M
safe_mode_exec_dir = ""
safe_mode_include_dir = "/nfsn/apps/php/lib/php/";
safe_mode_allowed_env_vars = TZ
safe_mode_gid = true
upload_max_filesize = 10M
sendmail_path = /nfsn/bin/sendmail -t -i
Example from httpd.conf:
php_admin_value open_basedir (3 dirs)
php_admin_value safe_mode 1
php_admin_value upload_tmp_dir /nfsn/content/example/tmp
php_admin_value max_execution_time 180
The file referenced in auto_prepend_file has one line:
<?php umask(0); ?>
------------------------------------------------------------------------
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
