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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
