ID: 47724 Comment by: scott at danielfamily dot com Reported By: scott at danielfamily dot com Status: No Feedback Bug Type: Reproducible crash Operating System: Centos 5.2 PHP Version: 5.2.9 New Comment:
We have since found another consistent failure case in a thread of code that is unrelated to the one reported here. It is another case where adding a single instruction makes the fault disappear. Previous Comments: ------------------------------------------------------------------------ [2009-03-31 12:10:48] peter at f-is dot eu Scott, thanks for your work at the VMWARE image, and Scott MacVicar for looking into it. I really hope this annoying bug finally get's fixed. I've been playing with Duma, Valgrind and GDB for a few days, but my knowledge about these tools, c programming, or the internals of PHP seem insufficient. >From what i can tell, this is a reference counting problem. Some object has 3 references, and than some time later the some memory location contains a String, with 1 reference, which gets dereferenced and de-allocated. During php shutdown, the original object is being read, and because the memory is 'gone' it segfaults. The String that seems to overwrite the object is being provided by the __toString function of the original object. So i guess something goes wrong there. I can't stress enough that my experience with C is extremely limited, so the above may be completely wrong :P. There is also no way for me to be sure that this is the same bug that Scott has, but the symptoms are the same. This is the information valgrind spits out about the crash is the following. Note that this only happens in crashing pages, or pages that sometimes crash, depending on input: ==29860== Invalid read of size 4 ==29860== at 0x63EBB7: _zval_ptr_dtor (zend_execute_API.c:410) ==29860== by 0x64F079: _zval_ptr_dtor_wrapper (zend_variables.c:177) ==29860== by 0x65F9C8: zend_hash_destroy (zend_hash.c:526) ==29860== by 0x64EC8A: _zval_dtor_func (zend_variables.c:45) ==29860== by 0x63E978: _zval_dtor (zend_variables.h:35) ==29860== by 0x63EC31: _zval_ptr_dtor (zend_execute_API.c:414) ==29860== by 0x64F079: _zval_ptr_dtor_wrapper (zend_variables.c:177) ==29860== by 0x65F9C8: zend_hash_destroy (zend_hash.c:526) ==29860== by 0x675161: zend_object_std_dtor (zend_objects.c:45) ==29860== by 0x675600: zend_objects_free_object_storage (zend_objects.c:122) ==29860== by 0x679E67: zend_objects_store_del_ref_by_handle (zend_objects_API.c:211) ==29860== by 0x679C45: zend_objects_store_del_ref (zend_objects_API.c:169) ==29860== Address 0xBF348B8 is 16 bytes inside a block of size 24 free'd ==29860== at 0x4A0541E: free (vg_replace_malloc.c:233) ==29860== by 0x62E4EB: _efree (zend_alloc.c:2303) ==29860== by 0x63ECD9: safe_free_zval_ptr_rel (zend_execute.h:70) ==29860== by 0x63EC51: _zval_ptr_dtor (zend_execute_API.c:415) ==29860== by 0x67D57C: zend_ptr_stack_clear_multiple (zend_execute.h:155) ==29860== by 0x67CE1E: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:307) ==29860== by 0x683160: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1729) ==29860== by 0x67C11B: execute (zend_vm_execute.h:92) ==29860== by 0x6951FA: ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER (zend_vm_execute.h:7811) ==29860== by 0x67C11B: execute (zend_vm_execute.h:92) ==29860== by 0x6517CC: zend_execute_scripts (zend.c:1134) ==29860== by 0x5F108F: php_execute_script (main.c:2023) This is the output of php that I got by enabling debugging options. They concern the same memory region as the above: Reducing refcount for bf348a8 (feff5738) type 5: 16->15 Reducing refcount for bf348a8 (feff5ba8) type 5: 15->14 Reducing refcount for bf348a8 (feff5cf0) type 5: 14->13 Reducing refcount for bf348a8 (bf45c08) type 5: 13->12 Reducing refcount for bf348a8 (bf45cc0) type 5: 12->11 Reducing refcount for bf348a8 (bf351a8) type 5: 11->10 Reducing refcount for bf348a8 (a0a518) type 5: 10->9 Reducing refcount for bf348a8 (feff84a8) type 5: 10->9 Reducing refcount for bf348a8 (bf350a8) type 5: 9->8 Reducing refcount for bf348a8 (a0a518) type 5: 8->7 Reducing refcount for bf348a8 (feff8d28) type 5: 7->6 Reducing refcount for bf348a8 (bf34b70) type 5: 6->5 Reducing refcount for bf348a8 (a0a518) type 5: 5->4 Reducing refcount for bf348a8 (a0a518) type 5: 4->3 Reducing refcount for bf348a8 (feffa048) type 6: 1->0 Destroying bf348a8 of type 6 Reducing refcount for bf348a8 (bf44e38) type 6: 0->-1 Reducing refcount for bf348a8 (bf35f70) type 6: -1->-2 ------------------------------------------------------------------------ [2009-03-31 03:21:39] scott at danielfamily dot com Scott MacVicar from the PHP team send me a note saying he would look at the bug. I uploaded the VMWARE appliance and send him the information, but have not heard back after some days. Still hoping for some love. ------------------------------------------------------------------------ [2009-03-31 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". ------------------------------------------------------------------------ [2009-03-23 19:14:17] scott at danielfamily dot com Thanks for the quick response. I understand that infinite recursion is a sure way to crash PHP. I've fixed those problems a bunch of times over the years. However, those bugs tend to manifest themselves in a consistent way. In this situation, removing code that is not even executed can cause the problem to disappear. Adding a few random instructions can also make the problem disappear. This would not happen if there was a recursion problem. This really feels like a heap corruption or some other wickedness in code A is causing a crash in code B where A and B are basically unrelated. These are REALLY REALLY hard to find and fix so I am sympathetic to your reluctance to dive in, but I believe this is a real problem. I've posted a ticket with the symfony team and hope that someone will respond (http://trac.symfony-project.org/ticket/6152), but as I say in that ticket, I believe the problem is with PHP, not symfony or doctrine. The symfony/doctrine stack simply represents the proper level of complexity to cause the PHP failure. Part of my persistence is that I believe it is very possible that this is related to Bug #40479 (http://bugs.php.net/bug.php?id=40479). I have some very negative experience with this problem on another project where my team spent nearly a man-month trying to find a random heap corruption problem. We ended up abandoning the Smarty based project and using Symfony with good results. In that case the problem was consistent, but intermittent. In this case, the problem is consistent and reproducible. ------------------------------------------------------------------------ [2009-03-23 18:08:14] ras...@php.net Are you sure this isn't a circular reference causing some sort of infinite recursion? There is no protection against infinite recursion crashes in 5.2.x ------------------------------------------------------------------------ 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/47724 -- Edit this bug report at http://bugs.php.net/?id=47724&edit=1
