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] [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); ?> ------------------------------------------------------------------------ [2005-01-14 21:39:53] [EMAIL PROTECTED] 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
