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:
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. Previous Comments: ------------------------------------------------------------------------ [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); ?> ------------------------------------------------------------------------ [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
