#31558 [Opn->Fbk]: FATAL: erealloc(): Unable to allocate ### bytes

ID: 31558 Updated by: sniper@php.net 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: 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. Previous Comments: ------------------------------------------------------------------------ [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