Edit report at https://bugs.php.net/bug.php?id=60598&edit=1
ID: 60598 Comment by: arjen at react dot com Reported by: arekm at maven dot pl Summary: cli/apache sapi segfault on objects manipulation Status: Open Type: Bug Package: Reproducible crash Operating System: Linux PHP Version: 5.4.0RC3 Block user comment: N Private report: N New Comment: Problem still present in php-5.4.15 verified from php.net src. See https://gist.github.com/anonymous/5713352 for bt. Previous Comments: ------------------------------------------------------------------------ [2012-11-25 15:07:30] manuel-php at mausz dot at Same on git master: [object_properties_init] name=Object addr=2e3b42b0 pt_addr=2e3b6270 pt[0]_addr=2e3b4dc8 pt[0].handle=#0 [zend_std_write_property] name=_guid (=pt[0]) old_addr=2e3b4dc8 new_addr=2e3b42f8 new.handle=#0 [object_properties_init] name=Object addr=2e3b6688 pt_addr=2e3b6a60 pt[0]_addr=2e3b4dc8 pt[0].handle=#0 [zend_std_write_property] name=_guid (=pt[0]) old_addr=2e3b4dc8 new_addr=2e3b66d0 new.handle=#1 [zval_collect_white] adding zval to zval_to_free-list zval: addr=2e3b42f8 refcnt=2 handle=#0 [gc_collect_cycles] freeing zval zval: addr=2e3b42f8 refcnt=2 handle=#0 ^^ - 1st zval free [zend_object_std_dtor] object=Object addr=2e3b42b0 pt_addr=2e3b6270 calling zval_ptr_dtor for pt[0]_addr=2e3b42f8 pt[0].refcnt=1515870810 ^^ - 2nd zval free pt[0].handle=#1515870810 [zend_object_std_dtor] object=Object addr=2e3b6688 pt_addr=2e3b6a60 calling zval_ptr_dtor for pt[0]_addr=2e3b66d0 pt[0].refcnt=1 pt[0].handle=#1 Patch for my debug output: https://gist.github.com/095e8dc10c3e18afb3e6 I recommend enabling ZEND_MM_HEAP_PROTECTION. This is why refcnt+handle is 0x5a5a5a5a on 2nd free. ------------------------------------------------------------------------ [2012-11-25 08:57:04] arekm at maven dot pl Tested http://snaps.php.net/php5.4-latest.tar.gz and still happens. [arekm@ixion-pld ~/test/php5.4-201211250630]$ export LC_ALL=C [arekm@ixion-pld ~/test/php5.4-201211250630]$ ./sapi/cli/php -n ./a.php If you see this, try to increase OBJECT_COUNT to 100,000 zsh: segmentation fault ./sapi/cli/php -n ./a.php [arekm@ixion-pld ~/test/php5.4-201211250630]$ ./sapi/cli/php -n --version PHP 5.5.0-dev (cli) (built: Nov 25 2012 09:37:34) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies [arekm@ixion-pld ~/test/php5.4-201211250630]$ gdb --args ./sapi/cli/php -n ./a.php GNU gdb (GDB) 7.4.50-0.20120120.2 (PLD Linux) Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pld-linux". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/users/arekm/test/php5.4- 201211250630/sapi/cli/php...done. (gdb) r Starting program: /home/users/arekm/test/php5.4-201211250630/sapi/cli/php -n ./a.php [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". If you see this, try to increase OBJECT_COUNT to 100,000 Program received signal SIGSEGV, Segmentation fault. 0x00000000006810d2 in gc_zval_possible_root (zv=0x7ffff7fabe78) at /home/users/arekm/test/php5.4-201211250630/Zend/zend_gc.c:143 143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv); (gdb) bt #0 0x00000000006810d2 in gc_zval_possible_root (zv=0x7ffff7fabe78) at /home/users/arekm/test/php5.4-201211250630/Zend/zend_gc.c:143 #1 0x0000000000682ce7 in zend_object_std_dtor (object=0x7ffff7fabe48) at /home/users/arekm/test/php5.4-201211250630/Zend/zend_objects.c:54 #2 0x0000000000682d19 in zend_objects_free_object_storage (object=0x7ffff7fabe48) at /home/users/arekm/test/php5.4- 201211250630/Zend/zend_objects.c:137 #3 0x0000000000688398 in zend_objects_store_free_object_storage (objects=0xd0b260) at /home/users/arekm/test/php5.4- 201211250630/Zend/zend_objects_API.c:92 #4 0x0000000000655003 in shutdown_executor () at /home/users/arekm/test/php5.4- 201211250630/Zend/zend_execute_API.c:297 #5 0x00000000006632a6 in zend_deactivate () at /home/users/arekm/test/php5.4- 201211250630/Zend/zend.c:941 #6 0x00000000006050bd in php_request_shutdown (dummy=dummy@entry=0x0) at /home/users/arekm/test/php5.4-201211250630/main/main.c:1781 #7 0x00000000007072c4 in do_cli (argc=3, argv=0x7fffffffe968) at /home/users/arekm/test/php5.4-201211250630/sapi/cli/php_cli.c:1174 #8 0x0000000000422925 in main (argc=3, argv=0x7fffffffe968) at /home/users/arekm/test/php5.4-201211250630/sapi/cli/php_cli.c:1364 (gdb) l 138 * currently running GC */ 139 return; 140 } 141 142 if (zv->type == IS_OBJECT) { 143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv); 144 return; 145 } 146 147 GC_BENCH_INC(zval_possible_root); (gdb) built with: ./configure --prefix=$HOME/test/php5.4 --disable-dom --disable-simplexml on a Linux x86_64 [arekm@ixion-pld ~/test/php5.4-201211250630]$ gcc -v Reading specs from /usr/lib64/gcc/x86_64-pld-linux/4.7.2/specs COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-pld-linux/4.7.2/lto-wrapper Target: x86_64-pld-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local -- libdir=/usr/lib64 --libexecdir=/usr/lib64 --infodir=/usr/share/info -- mandir=/usr/share/man --x-libraries=/usr/lib64 --enable-bootstrap --disable- build-with-cxx --disable-build-poststage1-with-cxx --enable-c99 --enable- checking=release --disable-cld --enable-cloog-backend=isl --enable-cmath -- enable-decimal-float --enable-gnu-unique-object --enable-initfini-array -- enable-languages=c,c++,fortran,objc,obj-c++,ada,java,go --enable-libgomp -- enable-libitm --enable-libmudflap --enable-linker-build-id --enable-linux-futex --enable-long-long --enable-nls --enable-lto --enable-plugin --enable-shared -- enable-threads=posix --disable-werror --with-cloog --with-demangler-in-ld -- with-gnu-as --with-gnu-ld --with-linker-hash-style=gnu --with-long-double-128 -- with-ppl --with-slibdir=/lib64 --without-system-libunwind --with-system-zlib -- enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch -- enable-libstdcxx-threads --enable-libstdcxx-time=rt --enable-libstdcxx- visibility --enable-symvers=gnu --with-gxx-include-dir=/usr/include/c++/4.7.2 -- disable-gconf-peer --enable-gtk-cairo --enable-java-awt=xlib,gtk --enable-jni -- enable-libgcj --enable-libgcj-multifile --enable-libgcj-database --disable- libjava-multilib --enable-static-libjava --enable-xmlj --with-pkgversion=PLD- Linux --with-bugurl=http://bugs.pld-linux.org x86_64-pld-linux Thread model: posix gcc version 4.7.2 20121104 (release) (PLD-Linux) ------------------------------------------------------------------------ [2012-11-25 04:16:47] larue...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I can not reproduce this, could you please try with new version PHP-5.4.x? thanks ------------------------------------------------------------------------ [2012-11-24 17:46:34] manuel-php at mausz dot at Hi, I've tried to debug this yesterday but was unable to come up with a working fix. So I decided to share my results. Maybe someone with more in-depth knowledge of the php gc/heap can fix it more easily now. First of all: The problem is also reproducible with 2 (and more) objects. It just doesn't crash due to phps memory heap. The corruption occurs during PHPs garbage collection which kicks in just after __destruct() but before releasing the objects. Since GC_ROOT_BUFFER_MAX_ENTRIES is 10000 per default you'll see heap memory corruption warnings starting at 9994 objects (looks like 6 other zvals are created during startup). Reducing GC_ROOT_BUFFER_MAX_ENTRIES to 8 allows to reduce OBJECT_COUNT (in the example script from arekm) to 2. Another more simple solution is to call gc_collect_cycles() in __destruct() just after unset(...). So here comes my (stripped down) debug output (verified via valgrind + gdb): * GC_ROOT_BUFFER_MAX_ENTRIES=default (10k) * OBJECT_COUNT=2 * call gc_collect_cycles() in __destruct() * abbr.: pt ...(object) properties_table [...] [object_properties_init] name=Object addr=b20d9d88 pt_addr=b20d9808 pt[0]_addr=b20d6148 pt[0].handle=#0 [zend_std_write_property] name=_guid (=pt[0]) old_addr=b20d6148 new_addr=b20d9db8 new.handle=#0 [...] [zval_collect_white] adding zval to zval_to_free-list zval: addr=b20d9db8 refcnt=2 handle=#0 [gc_collect_cycles] freeing zval zval: addr=b20d9db8 refcnt=2 handle=#0 [...] [zend_object_std_dtor] object=Object addr=b20d9d88 pt_addr=b20d9808 calling zval_ptr_dtor for pt[0]_addr=b20d9db8 pt[0].handle=#-1307730616 [...] Hope this helps. ------------------------------------------------------------------------ [2012-03-16 15:56:14] eugen at kochuev dot com We also face the similar issue in symfony 1.4 project. Issue appears in %.3 and 5.4 versions and does not happen in 5.2. Disabling GC makes segfaults less frequent, but still does not solve the problem. ------------------------------------------------------------------------ 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 https://bugs.php.net/bug.php?id=60598 -- Edit this bug report at https://bugs.php.net/bug.php?id=60598&edit=1