Alan Pinstein wrote: > 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.
The easy way to solve it was to limit the array to less than 64K entries, which I did before I made my original post. The problem only showed up because of a bug causing the cache to grow in an unconstrained way. Thanks for the suggestion, but the reason I started this thread was because I wanted to make sure that this doesn't happen again, regardless of bad programming. Upgrading to PHP 5 is certainly a reasonable solution, it's been on our wishlist for a while. We will probably drop support for PHP 4 in MediaWiki 1.6 or 1.7, so that we can take advantage of the new features. Upgrading won't be a trivial task, we're apparently one of the larger PHP installations in the world, with about 100 servers running PHP, and there's a number of custom extensions to check as well. Still, it has to be done some time. -- Tim Starling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
