php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #47724 Reproducable segmenation fault using symfony and doctrine
Submitted: 2009-03-20 02:29 UTC Modified: 2009-03-31 01:00 UTC
Votes:10
Avg. Score:4.6 ± 0.7
Reproduced:10 of 10 (100.0%)
Same Version:8 (80.0%)
Same OS:6 (60.0%)
From: scott at danielfamily dot com Assigned:
Status: No Feedback Package: Reproducible crash
PHP Version: 5.2.9 OS: Centos 5.2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: scott at danielfamily dot com
New email:
PHP Version: OS:

 

 [2009-03-20 02:29 UTC] scott at danielfamily dot com 
Description:
------------
Sorry for the longer than asked for initial post, but I've spent many many hours profiling this problem to make this bug report.

Our project uses symfony framework with the doctrine database abstraction. We have had a number of crash sequences that are VERY hard to simplify and usually crash intermittently. I have isolated an instance that always crashes on our linux systems and usually crashes under windows.

If I change the order of code or add code, the problem may disappear temporarily only to resurface later after additional code modification have been made. I've done this several times, but have no confidence in deploying this kind of fix in a final released product.

After many many hours, I've built a vmware appliance with Centos 5.2 and the LAMP stack installed. It was built using the latest Apache and PHP source. It is built using the enable-debug switch and I've gotten a stack trace (included below). 

Running the vmware appliance and hitting a single url running from it's server causes the error every time.

If someone is assigned to this problem and communicates with me, I can send them the vmware appliance to run under windows. It is already setup with the software stack to reproduce and debug the problem. It should save many hours of configuration (at least it would for me).

I believe that it is very possible this related to Bug #40479. Unfortunately, I have some experience with this problem with another project and believe it is a very serious unresolved issue.

Actual result:
--------------
[root@localhost bin]# gdb /usr/local/apache2/bin/httpd
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run -X
Starting program: /usr/local/apache2/bin/httpd -X
[Thread debugging using libthread_db enabled]
[New Thread -1208129792 (LWP 22085)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208129792 (LWP 22085)]
0x01146ab9 in zend_if_strlen (ht=1, return_value=0xa682b40, return_value_ptr=0x0, this_ptr=0x0,
    return_value_used=1) at /root/Desktop/php-5.2.9/Zend/zend_builtin_functions.c:286
286             RETVAL_LONG(Z_STRLEN_PP(str));
(gdb) bt
#0  0x01146ab9 in zend_if_strlen (ht=1, return_value=0xa682b40, return_value_ptr=0x0,
    this_ptr=0x0, return_value_used=1) at /root/Desktop/php-5.2.9/Zend/zend_builtin_functions.c:286
#1  0x0115cc34 in zend_do_fcall_common_helper_SPEC (execute_data=0xbf826c24)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:200
#2  0x01162706 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbf826c24)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:1729
#3  0x0115c795 in execute (op_array=0xa6715f8) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#4  0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf826de4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#5  0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf826de4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#6  0x0115c795 in execute (op_array=0xb7d92f88)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#7  0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf8270b4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#8  0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf8270b4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#9  0x0115c795 in execute (op_array=0xa47e408) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#10 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf827434)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#11 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf827434)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#12 0x0115c795 in execute (op_array=0xb7d8bd58)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#13 0x0119df6a in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER (execute_data=0xbf827734)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:20117
#14 0x0115c795 in execute (op_array=0xb7d7d784)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#15 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf827e64)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#16 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf827e64)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#17 0x0115c795 in execute (op_array=0xb7d69dc0)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#18 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf828274)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#19 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf828274)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#20 0x0115c795 in execute (op_array=0xa403ce0) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#21 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf8283e4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#22 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf8283e4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#23 0x0115c795 in execute (op_array=0xa403c18) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#24 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf8285e4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#25 0x01162706 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbf8285e4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:1729
#26 0x0115c795 in execute (op_array=0xb7d76d80)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#27 0x0119df6a in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER (execute_data=0xbf8288e4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:20117
#28 0x0115c795 in execute (op_array=0xb7d7d784)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#29 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf829014)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#30 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf829014)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#31 0x0115c795 in execute (op_array=0xb7d69dc0)
---Type <return> to continue, or q <return> to quit---
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#32 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf829424)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#33 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf829424)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#34 0x0115c795 in execute (op_array=0xa403ce0) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#35 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf829594)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#36 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf829594)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#37 0x0115c795 in execute (op_array=0xa403c18) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#38 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf8297d4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#39 0x01162706 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbf8297d4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:1729
#40 0x0115c795 in execute (op_array=0xb7d678ac)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#41 0x0119df6a in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER (execute_data=0xbf829ad4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:20117
#42 0x0115c795 in execute (op_array=0xa618b40) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#43 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf82a104)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#44 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf82a104)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#45 0x0115c795 in execute (op_array=0xa61ad54) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#46 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf82a574)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#47 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf82a574)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#48 0x0115c795 in execute (op_array=0xa446d64) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#49 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf82a854)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#50 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf82a854)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#51 0x0115c795 in execute (op_array=0xa446180) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#52 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf82ad34)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#53 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf82ad34)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#54 0x0115c795 in execute (op_array=0xa438670) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#55 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf82b0d4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#56 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf82b0d4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#57 0x0115c795 in execute (op_array=0xa430580) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#58 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf82b544)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#59 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf82b544)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#60 0x0115c795 in execute (op_array=0xa43887c) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#61 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf82b8e4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#62 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf82b8e4)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#63 0x0115c795 in execute (op_array=0xa430580) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#64 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf82bb74)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#65 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf82bb74)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
---Type <return> to continue, or q <return> to quit---
#66 0x0115c795 in execute (op_array=0xa43fb28) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#67 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf82bf14)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#68 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf82bf14)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#69 0x0115c795 in execute (op_array=0xa430580) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#70 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf82cb94)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#71 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf82cb94)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#72 0x0115c795 in execute (op_array=0x9f388e0) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#73 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf82cf74)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#74 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf82cf74)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#75 0x0115c795 in execute (op_array=0x9f27344) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#76 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf82d104)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#77 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf82d104)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#78 0x0115c795 in execute (op_array=0x9e0b748) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#79 0x0115cdae in zend_do_fcall_common_helper_SPEC (execute_data=0xbf82d324)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:234
#80 0x0115d888 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf82d324)
    at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:322
#81 0x0115c795 in execute (op_array=0x9c5989c) at /root/Desktop/php-5.2.9/Zend/zend_vm_execute.h:92
#82 0x011375d7 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /root/Desktop/php-5.2.9/Zend/zend.c:1134
#83 0x010e4bb6 in php_execute_script (primary_file=0xbf82f664)
    at /root/Desktop/php-5.2.9/main/main.c:2023
#84 0x011b4619 in php_handler (r=0x9c90fe0)
    at /root/Desktop/php-5.2.9/sapi/apache2handler/sapi_apache2.c:632
#85 0x08076b89 in ap_run_handler (r=0x9c90fe0) at config.c:157
#86 0x08079cf7 in ap_invoke_handler (r=0x9c90fe0) at config.c:372
#87 0x08090998 in ap_process_request (r=0x9c90fe0) at http_request.c:282
#88 0x0808dbab in ap_process_http_connection (c=0x9c8ce20) at http_core.c:190
#89 0x0807dbd9 in ap_run_process_connection (c=0x9c8ce20) at connection.c:43
#90 0x080a4035 in child_main (child_num_arg=<value optimized out>) at prefork.c:650
#91 0x080a4263 in make_child (s=0x9ab1ce0, slot=0) at prefork.c:690
#92 0x080a503c in ap_mpm_run (_pconf=0x9aad0a8, plog=0x9aeb1a0, s=0x9ab1ce0) at prefork.c:966
#93 0x08064695 in main (argc=162181280, argv=0x9c8ac40) at main.c:740
(gdb)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-03-21 23:03 UTC] jani@php.net 
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.
 [2009-03-22 17:38 UTC] scott at danielfamily dot com 
I understand and appreciate the purpose of the canned response, but please reread my original bug submission. What you are asking for is impossible. Duplication of the problem REQUIRES a very complex sequence of PHP code. If I change a single line of PHP code, the problem is likely to disappear. 

Please take me up on my offer to transfer the VMWARE appliance that clearly and consistently duplicates the problem.
 [2009-03-22 18:00 UTC] pajoye@php.net 
If you are not able to create a self contained script to reproduce the problem, report the bug to symfony or doctrine developers and ask them to analyze it. We can't use these tools as a base to debug this issue.

Thanks for your understanding.
 [2009-03-23 17:56 UTC] scott at danielfamily dot com 
I believe very strongly that this is a bug in PHP, not in doctrine or symfony. Modifying seemingly random and benign pieces of code, changing the order of code, or collapsing classes usually results in the problem disappearing. This makes it impossible to comply with your request for a simple script.

This is VERY likely to be a corrupt heap situation that only manifests itself when the planets are aligned correctly. I have gotten those planets to align consistently and the crash always happens.

I'm willing to do anything reasonable to get someone to look at this problem. Building the VMWARE appliance seemed like the best approach as it will allow someone familiar with the internals of PHP to download the appliance and duplicate the problem in minutes.

I've already posted this on the symfony forums and gotten sympathy, but no substitive suggestions. I'll try posting it as a symfony bug and see what happens.
 [2009-03-23 18:08 UTC] rasmus@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
 [2009-03-23 19:14 UTC] 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-31 01:00 UTC] 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-31 03:21 UTC] 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 12:10 UTC] 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-04-02 16:41 UTC] scott at danielfamily dot com 
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.
 [2010-04-02 18:01 UTC] mustafa at mustafaaltun dot com 
Scott, thank you for your effort to solve this issue. Is there any good news from php side? Or do you have any symfony-doctrine solution?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Apr 16 04:01:27 2024 UTC