Two things to try: - run it under valgrind to see if it highlights code problems - try it on a different box. If it works on the other box, consider testing your ram as it may be faulty.
--Wez. On 10/18/06, Gwynne <[EMAIL PROTECTED]> wrote:
I'm experiencing a strange random crash in PHP 5.1.4 and 5.1.6 triggered by several separate sections of code under a number of circumstances. I can't narrow it down much, but the backtrace always ends with: (gdb) bt #0 0x081f80fe in _erealloc (ptr=0x8531b44, size=2, allow_failure=0) at ./src/php-5.1.6/Zend/zend_alloc.c:387 #1 0x08206e54 in add_string_to_string (result=0xbfffb7f0, op1=0xbfffb7f0, op2=0x8520cb4) at ./src/php-5.1.6/Zend/ zend_operators.c:1138 #2 0x0822b36c in ZEND_ADD_STRING_SPEC_TMP_CONST_HANDLER (execute_data=0xbfffb880) at zend_vm_execute.h:5019 #3 0x08229718 in execute (op_array=0x851f590) at zend_vm_execute.h:92 #4 0x08229b97 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffba80) at zend_vm_execute.h:234 or (gdb) bt #0 0x4068c654 in mallopt () from /lib/libc.so.6 #1 0x4068b220 in realloc () from /lib/libc.so.6 #2 0x081f811b in _erealloc (ptr=0x858d230, size=30, allow_failure=0) at ./src/php-5.1.6/Zend/zend_alloc.c:388 #3 0x08206e54 in add_string_to_string (result=0xbfffbdd8, op1=0xbfffbdd8, op2=0x852e284) at ./src/php-5.1.6/Zend/ zend_operators.c:1138 #4 0x0822b36c in ZEND_ADD_STRING_SPEC_TMP_CONST_HANDLER (execute_data=0xbfffc1a0) at zend_vm_execute.h:5019 #5 0x08229718 in execute (op_array=0x8531cc0) at zend_vm_execute.h:92 #6 0x08229b97 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffc3c0) at zend_vm_execute.h:234 The PHP code in question is rather complicated and I've tried and failed to isolate a smaller section that might be triggering this. This PHP is built on i686-pc-linux-gnu (GNU/Linux 2.4.32), using both GCC 3.3.5 and 4.0.2 (no difference between builds made with one vs the other) with the following configure line: ./configure --prefix=$HOME/builds --enable-cgi --enable-force-cgi- redirect --enable-cli --disable-short-tags --with-zlib --disable-ftp --with-iconv=$HOME/builds --with-iconv-dir=$HOME/builds --with-mysql=/ usr --enable-sockets --disable-debug --with-xsl=$HOME/builds --enable- bcmath --with-gmp=$HOME/builds --with-imap=$HOME/builds/imap --with- imap-ssl=/usr --with-xmlrpc --with-xml-dir=$HOME/builds --with- mysqli=/usr/bin/mysql_config --disable-maintainer-zts --enable-zend- multibyte --disable-mbstring --without-gd --enable-memory-limit -- with-expat-dir=$HOME/builds --without-sqlite --disable-pdo --disable- spl --disable-tokenizer --disable-simplexml --disable-ipv6 --with- openssl=/usr --disable-pear --disable-spl --enable-discard-path -- enable-xmlreader --enable-xmlwriter --enable-zip --with-libxml-dir= $HOME/builds --with-mcrypt=$HOME/builds I have two custom-built extensions loading into PHP as well, but I was able to eliminate them as the source of the problem by disabling them entirely and verifying that it made no difference. Obviously, I'm using the CGI SAPI. If I build with --enable-debug, the issue immediately vanishes. My only guess at this would be some kind of memory stomper, but I don't know enough about PHP internals to track it down. I ran the full testsuite on every build (both 5.1.4 and 5.1.6 showed exactly the same symptoms) with perfect results (save the tests that always fail under normal circumstances). Can anyone offer any thoughts? I can't post the scripts I'm using, but I need a non-"use the debug version and hope" solution if one exists. -- Gwynne, Daughter of the Code "This whole world is an asylum for the incurable." -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
