Well I tried for a few hours but cannot create a simple test that duplicates the results. Although my results varied and the same code blocks did not consistently hang from test to test, the total script would always hang.

Before giving up when it seemed the behavior changed, I thought this was related to:
Caching object instances as array entries of static arrays declared inside a getObject method, inside other objects that were cached in the same way in higher level objects (depth of 3 or higher), then starting from the highest-level object, trying to retrieve the deep objects. But I cannot be sure because the simple test succeeds, and it seemed like the original script would hang on the return statements, which makes it nearly impossible to debug further from within PHP.

As I said, this worked properly in previous commits, but the last commit I tried before today is dated 11/6/2014, so I am not sure when the breaking change occurred. I will try to at least narrow it down to the last date with a working commit and report back.

By testing with various old commits, I have determined that the breaking change occurred somewhere between the following:
- 54fa42475120f3ab61f50732fa2d68c3af07f259 (works)
- 96220027e12d72b295808081136dee66bc3a9d61 (does not work)

The commits between the two look relatively innocuous, so I'm at a bit of a loss regarding how to narrow it down further.

Finally narrowed it down to a single commit.

This was the breaking change: http://git.php.net/?p=php-src.git;a=commitdiff;h=76019b86c0ede959e000c164b02ed8b1d8bb29e1

I'm not sure why that matters, but I think that change needs to be rolled back, or it at least needs to be investigated why it causes returns of object instances stored as local static array entries to sometimes hang.

I suppose this could matter if you have shared extensions that you didn't recompile after that change since the order changed in that Bucket struct. Check that all your .so extensions were compiled against this new struct layout.

The only extension in my php.ini is
zend_extension = "opcache.so"

I was under the impression that this recompiles in tandem with every PHP recompile, as I've never actually compiled that module manually.

Well, just check the timestamp

Yes, I just recompiled again and the timestamp is updated on opcache.so. But like I said removing that extension from php.ini to disable it has no effect, so it's not hanging because of any extension I've defined there.

However, I am seeing these warnings when compiling now. Not sure what to do about them:
/usr/bin/ld: warning: libssl.so.10, needed by /usr/lib64/libssh2.so.1, may conflict with libssl.so.1.0.0
/usr/bin/ld: warning: libssl.so.10, needed by /usr/lib64/libssh2.so.1, may conflict with libssl.so.1.0.0
/usr/bin/ld: warning: libcrypto.so.10, needed by /usr/lib64/libssh2.so.1, may conflict with libcrypto.so.1.0.0
/usr/bin/ld: warning: libcrypto.so.10, needed by /usr/lib64/libssh2.so.1, may conflict with libcrypto.so.1.0.0
/usr/bin/ld: warning: libcrypto.so.10, needed by /usr/lib64/libssh2.so.1, may conflict with libcrypto.so.1.0.0
/usr/bin/ld: warning: libcrypto.so.10, needed by /usr/lib64/libssh2.so.1, may conflict with libcrypto.so.1.0.0

You did a full "make distclean && ./buildconf -f" ?

I always remove the build directory completely before attempting a new update. Even so, I did what you suggested and there was no change in this behavior. I then went and manually removed the conflicting libs it was complaining about, and on the next compile there were no complaints. There was still no change in this behavior.

I have a feeling that there is somewhere else in PHP internals that is not expecting the new Bucket definition, that still might be somehow coded for the old one. Or perhaps there is a location that is not using the Bucket at all when it should be.

To check my suspicions from my first post, I then went and compiled PHP as debug-zts. As I suspected, this works properly. So it is only no-debug builds that are affected by this bug.

Recompiled today using the newest commit into a completely different --prefix, in case there was conflicting data in the old --prefix. This made absolutely no difference; PHP still hangs unless --enable-debug is used.

Now over 1 month later I tried the newest update with no change. Since it seems like an infinite loop occurs, I reworked a recursive class so it no longer accesses itself recursively. This seems to have eliminated the infinite loop in PHP master, although the recursion worked without issue in PHP 5.6.x and lower.

With this change, the script now actually shows an error message (whether it was the core issue originally or it is a new issue, I cannot be sure). However, the script still will not complete execution because of the following error:

Fatal error: Cannot redeclare class [class_already_declared] in [file_that_doesnt_declare_that_class_at_all] on line 0

This new error makes absolutely no sense. It always happens when using require_once on a specific file and always claims the same class is trying to redeclare, but that file does not so much as mention the name of the class. And the "on line 0" is no help either.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

I have provided feedback several times since opening this bug. The last time was only a few days ago. No one has responded to me with any suggestions with getting to the bottom of it for some time. There is a difference. Please make a real response before auto-closing it next time.

Here is my configure line. Is there anything that stands out extension-wise that may need to be updated? What are the minimum version requirements of the various dependencies?

./configure --without-pear --enable-bcmath --enable-libxml --enable-mbstring --enable-sockets --enable-fpm --prefix=/home/php --with-curl --with-gd --with-jpeg-dir=/usr --with-libdir=/lib64 --with-libxml-dir=/usr/lib64/ --with-mcrypt --with-mysql --with-mysqli --with-openssl=/usr --with-pic --with-png-dir=/usr --with-xpm-dir=/usr --with-xsl --with-zlib --with-zlib-dir=/usr --with-fpm-user --with-fpm-group

As noted, I cannot reproduce this problem using this test script. However, this test script is lifted almost completely (with classes and methods renamed) from the script that hangs indefinitely.

I am hoping that it at least gives you some idea as to the problem I am encountering. In the original script, the var_dump() line never occurs. However, as soon as the preceding $arr line is commented out, the var_dump() occurs. In the original script, it actually does not matter what the preceding line is: as long as the preceding line uses $item in some way, the script hangs.

### main script ###

require_once('./hello.php');

$test = new Test();
$props = new Test_prop();

$test->set_info($props);
$test->execute();

echo 'done';

exit;

#### hello.php ####

class Test_prop
{
	public $id = 0;

	public $title = '';
}

class Test
{
	protected $stack = array();

	function set_info($props)
	{
		$this->stack = array();
		$item = $this->get_item();

		if (!$item)
		{
			$item = array(
				'id' => $props->id,
				'title' => $props->title,
				'key' => 'Error'
			);

			$this->stack[] = $item;

			return;
		}
	}

	function get_item()
	{
		return false;
	}

	function execute($do_output = true)
	{
		reset($this->stack);
		$key = key($this->stack);
		$first =& $this->stack["$key"];

		if ($first['key'] != 'Error')
		{
			return;
		}

		foreach ($this->stack AS &$item)
		{
			$arr = array($item);
			var_dump($item);
		}
	}
}

This issue still persists as of March 11, 2015.

Just did a test and the hang only occurs when using php-fpm.
When processing the script directly using the command line, it completes as expected.

This appears to be fixed as of #d092cb6. Thanks.