ID: 20783 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: BSD/OS 4.2/FreeBSD-STABLE 4.7 PHP Version: 4.4CVS2002-12-03 New Comment:
Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The crash occures because Zend will die with SEGV when emalloc cannot allocate more memory when --enable-debug is on. In this situation the account had a hard memory limit, which PHP exceeded, when it could not allocate more memory it crashed. Not a PHP bug. Previous Comments: ------------------------------------------------------------------------ [2002-12-09 12:39:12] [EMAIL PROTECTED] The debug build with intentionally die with a Segv when emalloc cannot allocate memory. ------------------------------------------------------------------------ [2002-12-03 10:43:08] [EMAIL PROTECTED] And here we go: (gdb) frame 5 #5 0x814e842 in vspprintf (pbuf=0xbfbfddf8, max_len=1024, format=0x81ce420 "Maximum execution time of %d second%s exceeded", ap=0xbfbfde6c "\002") at /home/mdev/cvs/php4/main/spprintf.c:614 614 if (!xbuf_init(&xbuf, max_len)) { (gdb) info local xbuf = {buf = 0x0, size = 0, max_len = 1024, buf_end = 0x2839f67d "fflush", nextb = 0x2839f67d "fflush"} cc = 673076424 (gdb) frame 4 #4 0x814dd30 in xbuf_init (xbuf=0xbfbfdd98, max_len=1024) at /home/mdev/cvs/php4/main/spprintf.c:160 160 xbuf_resize(xbuf, 0); /* NOT max_len */ (gdb) info local No locals. (gdb) print *xbuf $5 = {buf = 0x0, size = 0, max_len = 1024, buf_end = 0x2839f67d "fflush", nextb = 0x2839f67d "fflush"} (gdb) frame 4 #4 0x814dd30 in xbuf_init (xbuf=0xbfbfdd98, max_len=1024) at /home/mdev/cvs/php4/main/spprintf.c:160 160 xbuf_resize(xbuf, 0); /* NOT max_len */ (gdb) print *xbuf $6 = {buf = 0x0, size = 0, max_len = 1024, buf_end = 0x2839f67d "fflush", nextb = 0x2839f67d "fflush"} (gdb) frame 3 #3 0x814dcab in xbuf_resize (xbuf=0xbfbfdd98, add=0) at /home/mdev/cvs/php4/main/spprintf.c:143 143 buf = erealloc(xbuf->buf, size+1); /* alloc space for NUL */ (gdb) print size $7 = 128 That's the 129 bytes. Notice that buf_end and nextb are equal. Additionally, in main/main.c: char *buffer; int buffer_len, display; TSRMLS_FETCH(); buffer_len = vspprintf(&buffer, PG(log_errors_max_len), format, args); Which yields: gdb) frame 6 #6 0x814ab05 in php_error_cb (type=1, error_filename=0x825c424 "/home/mdev/cvs/php4/test_while.php", error_lineno=14, format=0x81ce420 "Maximum execution time of %d second%s exceeded", args=0xbfbfde6c "\002") at /home/mdev/cvs/php4/main/main.c:533 533 buffer_len = vspprintf(&buffer, PG(log_errors_max_len), format, args); (gdb) print buffer $8 = 0x66e90a5 <Error reading address 0x66e90a5: Bad address> ------------------------------------------------------------------------ [2002-12-03 10:25:56] [EMAIL PROTECTED] For completeness: CFLAGS='-O0' \ ./configure \ --prefix=/phpct \ --with-apache=../apache_1.3.27 \ --enable-cli \ --disable-cgi \ --enable-debug \ --enable-magic-quotes \ --disable-short-tags \ --with-zlib \ --with-zlib-dir=/usr \ --enable-calendar \ --enable-ftp \ --with-mhash=/weblib/local \ --enable-shmop \ --enable-sysvmsg \ --enable-sysvsem \ --enable-sysvshm Derick: It may be frame #6: buffer = 0x2. This is typical for BSD's - if you do something like: char **buffer; buffer[0] = (char *)malloc(1024); Linux doesn't seem to mind as I see it in linux oriented packages, but BSD's do as buffer[0] hasn't been allocated. And: $ ./test_while.php buffer Running php 4.4.0-dev on FreeBSD Running script with memory limit: php in malloc(): warning: recursive call FATAL: emalloc(): Unable to allocate 129 bytes Segmentation fault (core dumped) ------------------------------------------------------------------------ [2002-12-03 09:55:24] [EMAIL PROTECTED] Script works fine for me on Linux... ------------------------------------------------------------------------ [2002-12-03 09:47:25] [EMAIL PROTECTED] Researched this some more, same for RC2. Reproducable script: #!/home/mdev/_src/php-4.3.0RC2/sapi/cli/php -q <?php set_time_limit(2); echo "Running php ", PHP_VERSION, "\n"; echo "Running script with memory limit:", ini_get('memory_limit'), "\n"; $i=0; define('LONG_STRING', str_repeat('x', 4096) . "\n"); $buffer =''; // yes this is intended. while($i > -1) { if(++$i % 10000 == 0) print "Still running: $i\n"; if(isset($argv[1]) && $argv[1] == 'buffer') $buffer.=LONG_STRING; } ?> Output: # ./test_while.php buffer Running php 4.3.0RC2 Running script with memory limit: FATAL: emalloc(): Unable to allocate 129 bytes Segmentation fault (core dumped) Omit the argument 'buffer' and the script finishes cleanly, after outputting some lines and reaching max_execution_time. The memory limit reference I put in, because: php -i | grep ini | sed -e "s|.*=> \(.*\)$|\1|" | xargs grep '^memory_limit' && php -r 'echo "Limit is: ", ini_get("memory_limit"), "\n";' Outputs: memory_limit = 16M ; Maximum amount of memory a script may consume (8MB) Limit is: This script doesn't come above 16M, the original script does however, which is probably another bug.. ------------------------------------------------------------------------ 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/20783 -- Edit this bug report at http://bugs.php.net/?id=20783&edit=1
