#23299 [Opn->Fbk]: Intermittant but reproducable corruption and crash

ID: 23299 Updated by: sniper@php.net Reported By: bginter at ndevtech dot net -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux 2.4.20 -PHP Version: 4.3.1 +PHP Version: 4.3.2-RC New Comment: Was this with the configure line I told you to use? Previous Comments: ------------------------------------------------------------------------ [2003-04-24 04:05:54] bginter at ndevtech dot net Here is the one from crash1.php in my examples: Program received signal SIGSEGV, Segmentation fault. 0x40415404 in zval_add_ref (p=0x8190a60) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_variables.c:85 85 (*p)->refcount++; (gdb) bt #0 0x40415404 in zval_add_ref (p=0x8190a60) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_variables.c:85 #1 0x4041dd38 in zend_hash_copy (target=0x81970dc, source=0x8193e5c, pCopyConstructor=0x404153fc <zval_add_ref>, tmp=0xbfffcbd4, size=4) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_hash.c:789 #2 0x40415651 in _zval_copy_ctor (zvalue=0x81889d4, __zend_filename=0x404e8180 "/usr/local/src/php4-STABLE-200304240730/Zend/zend_execute.c", __zend_lineno=1795) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_variables.c:137 #3 0x4042b131 in execute (op_array=0x8162cc4) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_execute.c:1795 #4 0x40417384 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php4-STABLE-200304240730/Zend/zend.c:864 #5 0x403db91e in php_execute_script (primary_file=0xbffff8c8) at /usr/local/src/php4-STABLE-200304240730/main/main.c:1637 [...] (gdb) frame 3 #3 0x4042b131 in execute (op_array=0x8162cc4) at /usr/local/src/php4-STABLE-200304240730/Zend/zend_execute.c:1795 1795 zval_copy_ctor(varptr); (gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name $1 = 0x0 (gdb) print (char *)executor_globals.active_op_array->function_name $2 = 0x0 (gdb) print (char *)executor_globals.active_op_array->filename $3 = 0x8162fb4 "/usr/local/apache/lariat/lariat2/test/test1/crash1.php" ------------------------------------------------------------------------ [2003-04-24 03:38:42] sniper@php.net 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 And use EXACTLY this configure line: ./configure \ --prefix=/usr/local/php_4.3.1 \ --with-apxs=/usr/local/apache/bin/apxs \ --enable-bcmath \ --enable-gd-native-ttf \ --with-gd \ --with-ttf \ --enable-calendar \ --with-mysql \ --with-openssl \ --with-iconv \ --enable-xml \ --with-pgsql=/usr/local/pgsql-7.3 \ --with-mcrypt \ --with-curl \ --with-zip \ --enable-ftp \ --with-zlib-dir=/usr \ --enable-debug Also, disable Zend optimizer and generate the GDB backtrace as instructed here: http://bugs.php.net/bugs-generating-backtrace.php And DO NOT ADD THE FULL backtrace here!! only the relevant part of it, usually the 15-20 first lines. ------------------------------------------------------------------------ [2003-04-23 17:56:31] bginter at ndevtech dot net I have created some example code to illustrate this bug. It's available at: http://www.lariatcentral.com/test1.tar.gz There are two cases in the file: * one consistantly causes corruption and often a crash * one consistantly always causes a segmentation fault There are several classes in this package. It may have been possible to make this example more concise but I haven't had any success doing so. There is also a file called backtrace.txt that shows the three main crashes I am seeing. I believe we are tickling this bug in a much more subtle way in our code. If we knew why this was happening we could change the code to "not do that", PHP should not be segfaulting or corrupting data. I have tested this example on two servers and it worked (corrupted/crashed) on both. You might try fiddling with the set_time_limit() to change the way the corruption is visible. Let me know how I can assist you further. Thanks. ------------------------------------------------------------------------ [2003-04-22 22:58:15] rasmus@php.net Wow, that sounds like an insanely complex piece of PHP code. It sounds like you are indeed hitting some odd bug, but unless you can come up with a way for us to reproduce it on our dev boxes I don't see how we can help you. ------------------------------------------------------------------------ [2003-04-21 16:01:44] bginter at ndevtech dot net I am experiencing an intermittant but reproducable problem with data, function names, method names, and objects being corrupted and often crashing Apache. This problem has been reoccurring periodically since around PHP 4.2.0 and continues to occur in 4.3.1. Unfortunately, the code that causes these errors to occur is quite large and attempts to create a small test case have been unsuccessful. Some examples of the corruption are provided below: Example 1: Script startup calling require_once(). /usr/local/apache/lariat/lariat2/find.php(14) : Fatal error - Cannot redeclare findup() (previously declared in ÈM@4:14) Example 2: Passing an array by value to a function. Array ( [0] => Ä 9 [Corrupted] [1] => DC [2] => 28 [3] => 334.87 [4] => Ä 9 [Corrupted] [5] => 0.00 [6] => 1825 ) PHP is running under Apache 1.3.27 and is compiled with the following options: ./configure \ --prefix=/usr/local/php_4.3.1 \ --with-apxs=/usr/local/apache/bin/apxs \ --enable-bcmath \ --enable-gd-native-ttf \ --with-gd \ --with-ttf \ --enable-calendar \ --with-mysql \ --enable-trans-sid \ --enable-inline-optimization \ --enable-track-vars \ --enable-versioning \ --with-openssl \ --with-iconv \ --enable-xml \ --with-pgsql=/usr/local/pgsql-7.3 \ --with-mcrypt \ --with-curl \ --with-zip \ --enable-ftp \ --with-zlib-dir=/usr \ --enable-debug Here is the backtrace: Program received signal SIGSEGV, Segmentation fault. 0x404053e0 in object.11 () from /usr/local/apache/libexec/libphp4.so.debug (gdb) bt #0 0x404053e0 in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #1 0x405382cc in php4_module () from /usr/local/apache/libexec/libphp4.so.debug #2 0x4040f93d in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #3 0x4041740a in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #4 0x4040f569 in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #5 0x4040540c in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #6 0x4040f93d in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #7 0x4041740a in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #8 0x4040f5b3 in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #9 0x4040540c in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #10 0x4040f93d in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #11 0x4041740a in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #12 0x4040f5b3 in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #13 0x4040540c in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #14 0x4040f93d in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #15 0x4041740a in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #16 0x4040f5b3 in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #17 0x4040540c in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #18 0x4040f93d in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #19 0x4041740a in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #20 0x40404ed7 in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #21 0x40410cd3 in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #22 0x403d4e5b in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #23 0x40429b48 in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #24 0x4042aa70 in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #25 0x4042aaef in object.11 () from /usr/local/apache/libexec/libphp4.so.debug #26 0x080554e9 in ap_invoke_handler () #27 0x0806b5df in process_request_internal () #28 0x0806b646 in ap_process_request () #29 0x08061e06 in child_main () #30 0x08061fe5 in make_child () #31 0x0806215c in startup_children () #32 0x080627ed in standalone_main () #33 0x0806307c in main () #34 0x4009214f in __libc_start_main () from /lib/libc.so.6 (gdb) Apache is linked to the following libraries: $ ldd /usr/local/apache/bin/httpd libm.so.6 => /lib/libm.so.6 (0x4001a000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4003b000) libdb.so.2 => /lib/libdb.so.2 (0x40069000) libdl.so.2 => /lib/libdl.so.2 (0x40076000) libc.so.6 => /lib/libc.so.6 (0x40079000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) The PHP module is linked as follows: $ ldd /usr/local/apache/libexec/libphp4.so.debug libzzip-0.so.10 => /usr/local/lib/libzzip-0.so.10 (0x4031f000) libpq.so.2 => /usr/local/pgsql-7.3/lib/libpq.so.2 (0x40325000) libmcrypt.so.4 => /usr/lib/libmcrypt.so.4 (0x4033c000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0x40342000) libpng.so.2 => /usr/lib/libpng.so.2 (0x40348000) libz.so.1 => /usr/lib/libz.so.1 (0x40373000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40382000) libresolv.so.2 => /lib/libresolv.so.2 (0x403af000) libm.so.6 => /lib/libm.so.6 (0x403bf000) libdl.so.2 => /lib/libdl.so.2 (0x403e1000) libnsl.so.1 => /lib/libnsl.so.1 (0x403e4000) libcurl.so.2 => /usr/local/lib/libcurl.so.2 (0x403f8000) libc.so.6 => /lib/libc.so.6 (0x40415000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) Please let me know if I can provide any other information to help isolate the cause of this problem. Thank you for investigating. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=23299&edit=1