Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21456 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11814 invoked by uid 1010); 10 Jan 2006 01:32:56 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 11799 invoked from network); 10 Jan 2006 01:32:56 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Jan 2006 01:32:56 -0000 X-Host-Fingerprint: 202.63.61.242 cust3058.vic01.dataco.com.au Received: from ([202.63.61.242:6671] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id E6/00-10207-7CE03C34 for ; Mon, 09 Jan 2006 20:32:55 -0500 Message-ID: To: internals@lists.php.net Date: Tue, 10 Jan 2006 12:33:29 +1100 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <31.AA.06465.0C74FB34@pb1.pair.com> <7.0.1.0.2.20060108171105.063406b0@zend.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Posted-By: 202.63.61.242 Subject: Re: [PHP-DEV] 16-bit reference count in PHP 4's zval From: t.starling@physics.unimelb.edu.au (Tim Starling) 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