Bug 31525 may be related to this one. The same section of code run under PHP 5.0.3 generates consistent errors. Under PHP 4.3.10 the problems range from a object reference error, to a core dump to Apache just spinning endlessly.

However, under PHP 5.0.3 the same section of code causes consistent and immediate errors. I've reproduced a much smaller body of code the demonstrates the PHP 5 problem. My intuition is that it's related. At least this one is demonstrable.

All info is contained in bug 31525 and in this article with sample code:

http://www.yml.com/homepage.html?COMP=clog_list&cmd=detail&cs_clog_entries_ref=149

(make sure the URL isn't chopped)

It may very well be something I'm doing since I'm doing some complicated object trees and reference passing, however I would think that in no case should the $this reference just get dropped or become an unknown type.

Same config with --enable-debug added, amongst many other leak messages this one stood out:

---------------------------------------
/usr/local/src/php-4.3.10/Zend/zend_execute.c(486) : Block 0x082A0698 status:
/usr/local/src/php-4.3.10/Zend/zend_variables.c(44) : Actual location (location
was relayed)
Beginning:      OK (allocated on /usr/local/src/php-4.3.10/Zend/zend_operators.c:1068, 10 bytes)
      End:      Overflown (magic=0x2A8FCC83 instead of 0x2A8FCC84)
                1 byte(s) overflown
---------------------------------------

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

Repeated the experiments using php4-STABLE-200501130530 using the same configure line as before. 

When configured without --enable-debug this one segfaults instead of spinning. When compiled with --enable-debug it displays lots of leak messages but no buffer overrun messages.

Please see the 5.0.3 bug I also filed which is one that I was able to create a relatively small sample script for. I believe it may be the same bug because at one time at the point where php 4.3.10 segfaulted it output an error saying that '$this' was not a valid object .. which is what's happening consistently in the 5.0.3 sample script. 

For this 4.3.11-dev bug I don't have a sample script. It's a case of a very large body of code where one particular setup causes the fault; change anything in the code and the fault moves. (symbol table corruption? buffer overrun?)

Running httpd in gdb with -F -X:
backtrace:

(gdb) run -F -X
Starting program: /usr/local/apache/bin/httpd -F -X
 
Program received signal SIGSEGV, Segmentation fault.
0x403090de in _erealloc (ptr=0x95d7728, size=16, allow_failure=0)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_alloc.c:328
328             REMOVE_POINTER_FROM_LIST(p);
(gdb) where
#0  0x403090de in _erealloc (ptr=0x95d7728, size=16, allow_failure=0)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_alloc.c:328
#1  0x40313e15 in add_string_to_string (result=0xbffeb804, op1=0xbffeb804,
    op2=0x83a3060)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_operators.c:1029
#2  0x40324547 in execute (op_array=0x8fb55dc)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_execute.c:1494
#3  0x40324e07 in execute (op_array=0x86f38ec)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_execute.c:1690
#4  0x40324e07 in execute (op_array=0x86f308c)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_execute.c:1690
#5  0x40324e07 in execute (op_array=0x81f1e3c)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_execute.c:1690
#6  0x40324e07 in execute (op_array=0x839c454)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_execute.c:1690
#7  0x40324e07 in execute (op_array=0x847b1cc)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_execute.c:1690
#8  0x40324e07 in execute (op_array=0x8494eec)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_execute.c:1690
#9  0x40324e07 in execute (op_array=0x86f38ec)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_execute.c:1690
#10 0x40324e07 in execute (op_array=0x86f308c)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_execute.c:1690
---Type <return> to continue, or q <return> to quit---

#11 0x40324e07 in execute (op_array=0x81f1e3c)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_execute.c:1690
#12 0x40324e07 in execute (op_array=0x839c454)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_execute.c:1690
#13 0x40324e07 in execute (op_array=0x847b1cc)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_execute.c:1690
#14 0x40324e07 in execute (op_array=0x8141758)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_execute.c:1690
#15 0x40324e07 in execute (op_array=0x81bc264)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend_execute.c:1690
#16 0x40316e5b in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /usr/local/src/php4-STABLE-200501130530/Zend/zend.c:900
#17 0x402f064b in php_execute_script (primary_file=0xbffff000)
    at /usr/local/src/php4-STABLE-200501130530/main/main.c:1739
#18 0x40328ece in apache_php_module_main (r=0x80ff634, display_source_mode=0)
    at /usr/local/src/php4-STABLE-200501130530/sapi/apache/sapi_apache.c:54
#19 0x403298fd in send_php (r=0x80ff634, display_source_mode=0, filename=0x0)
    at /usr/local/src/php4-STABLE-200501130530/sapi/apache/mod_php4.c:621
#20 0x40329aa1 in send_parsed_php (r=0x80ff634)
    at /usr/local/src/php4-STABLE-200501130530/sapi/apache/mod_php4.c:636

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 possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.

Unfortunately this is one of those bugs that I have not been able to create a short reproducing script. I think it's a symbol table corruption problem probably due to a buffer overflow problem in the parser code somewhere. If I change the PHP code slightly the location of the segfault changes. If I compile with --enable-debug it stops segfaulting.

If you are interested, with some work, I can provide you a test machine to log into with all my code on it and exact instructions on how to reproduce this problem. You are welcome to use my hardware to diagnose this problem. 

You may wish to look at bug http://bugs.php.net/31525 for which I do have a test script that I believe is related to this bug. 

I have added your sniper at php.net email to my whitelist, so please feel free to contact me directly. I am very motivated to help track this bug down and as I mentioned before it may very well be due to something I'm doing in my code. Aside from providing you a box to log into where the bug is demonstrated, is there anything else I can do to help track this down?

Do you have recursive function calls in your script?

yes, I make alot of use of recursion. It's a system that constructs trees of objects based on an XML source file. 

I do a tremendous amount of object reference passing as well.

The first version was built in 2001 and it's been growing since. I've run into several PHP symbol table corruption bugs since that time; most I haven't bothered to report since they're so difficult to reproduce. PHP versions since 4.3.4 have been /much/ more stable; until this bug which seems to be caused by a particular combination of object trees.

What you are experiencing is a stack smash caused by recurssion. This is unlikely to ever be fixed and is a good example of why not to use recursive functions.

Ummm. You're not really saying that PHP can't do recursion, are you? That would be ludicrous.

It can do that, but not infinitive recursion. The limit is about 2500 levels of function calls deep, but that may variate quite some depending on your situation.

Maybe we are miscommunicating. This is not an infinite recursion problem. As you can see in the bug reports below, if I compile PHP with --enable-debug it works like a champ (i.e. no spinning) and clearly lists PHP /INTERNAL/ buffer overruns in the debug log. 

This is not an endless recursion problem. It is most likely a symbol table or stack management bug.

At most I might have 20 levels of recursion when I parse XML documents but no more. 

As I've mentioned a few times I believe it may be similar or even related to a 100% reproducible PHP 5.0 bug that I have a test script for.

Problem found!

Turns out I have been incorrectly using ()'s in my returns from methods that return references as in:

function &someFunc()
{
return( $somevar );
}

this did not generate any errors and has worked for /ages/ in a very large body of code. 

However, it looks like this was causing the sit and spin phenomenon in rare case and also the array references/symbol table corruption problem I was noticing. (at least in test cases that were very reliably reproducing the problem.)

Makes one wonder why it worked at all.