Re: 16-bit reference count in PHP 4's zval

It seems that the problem you're encountering could be fixed trivially by moving the initialization of $stuff into the constructor. However, it's difficult to tell from the provided code whether $stuff is intended as a static member... but if it's not, seems like a very simple fix... I don't personally know about PHP4 internals, but it would seem that the reason it breaks as-is is that ALL CacheEntry objects initially report to the same (statically created) empty array. So, moving it into the constructor would at least create n empty arrays rather than segfaulting. Right? Then you wouldn't even need to change your runtime environment (ie PHP version) to solve the problem. Alan On Jan 8, 2006, at 5:00 PM, Tim Starling wrote:

Zeev Suraski wrote:

Tim, Your analysis was correct until the last sentence - PHP surely does support arrays with more than 64K entries. It just doesn't support the same entry being linked from more than 64K locations (which is much, much more rare occurrence).

Well yes, I was just stirring. It's more common than you might think though. My own case was somewhat similar to this: <? class CacheEntry {

        var $name;
        var $stuff = array();

        function CacheEntry( $name ) {
                $this->name = $name;
        }

} $cache = array(); for ( $i=0; $i<100000; $i++) {

        $cache[] = new CacheEntry( "Cache entry $i" );

} ?> ...which will segfault on exit due to the excess references to the empty array object created for the initialisation of the unused member variable $stuff. Generally speaking, arrays of objects with initialised but unused member variables will cause problems. Our code (MediaWiki) has plenty of such arrays, the reason we don't see this more often is because the arrays usually contain less than 64K entries. The size of the arrays depend on user input. -- Tim Starling --PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php