ID: 31558
User updated by: jdw at nearlyfreespeech dot net
Reported By: jdw at nearlyfreespeech dot net
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: FreeBSD
PHP Version: 4.3.10
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2005-01-15 00:16:00] sniper@php.net
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); ?>
------------------------------------------------------------------------
[2005-01-14 21:39:53] tony2001@php.net
What's your PHP configuration? Any Zend modules enabled?
Any chance to replicate the problem with strace httpd -X?
The info you've provided is pretty useless ATM as we don't have your
configuration and we're unable to reproduce the problem.
------------------------------------------------------------------------
[2005-01-14 19:44:06] jdw at nearlyfreespeech dot net
Description:
------------
We have seen this error under the following conditions
- FreeBSD 4-STABLE
- Using Apache 1.3.33
- PHP 4.3.10
- multiple servers
- servers have hundreds of megs of available RAM and gigs of free swap
- httpd processes are well within resource limits
- happens with random PHP scripts, even simple pages that don't use
much memory
- pages that generate the error may work if immediately reloaded
(unchanged with respect to code and data), suggesting that this is not
a per-request memory limit being exceeded
- almost always happens *before* headers are sent
- occurs on pages not using gzip or zlib or output compression or
anything else that would defer content output
- happens with alloc amounts from 7500 bytes to about 1meg, averaging
between 100-300k.
- happens in repetitive "clusters"
Problem persists across "apachectl graceful" but "goes away" (for
awhile at least) after "apachectl restart" so the Apache parent process
may tie in somehow.
Is there a way I can obtain more helpful debug information about this
in a production environment?
Thanks for any help with this!
Reproduce code:
---------------
n/a... virtually any PHP page appears susceptible, which is consistent
with the observation that it occurs before headers are sent.
Expected result:
----------------
PHP script should run.
Actual result:
--------------
Example from Apache error log: (all messages appear in immediate
succession)
FATAL: erealloc(): Unable to allocate 7500 bytes
FATAL: erealloc(): Unable to allocate 7500 bytes
FATAL: erealloc(): Unable to allocate 7500 bytes
FATAL: erealloc(): Unable to allocate 7500 bytes
FATAL: erealloc(): Unable to allocate 7500 bytes
FATAL: erealloc(): Unable to allocate 7500 bytes
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=31558&edit=1