Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21447
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <7.0.1.0.2.20060108171105.063406b0@zend.com>
Date: Sun, 08 Jan 2006 17:12:35 +0200
To: Tim Starling <t.starling@physics.unimelb.edu.au>
Cc: internals@lists.php.net
In-Reply-To: <31.AA.06465.0C74FB34@pb1.pair.com>
References: <31.AA.06465.0C74FB34@pb1.pair.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] 16-bit reference count in PHP 4's zval
From: zeev@zend.com (Zeev Suraski)

At 06:47 07/01/2006, Tim Starling wrote:
>I've had some trouble with large arrays in my PHP programs causing
>corruption of the heap. I tracked the problem back to PHP 4's 16-bit
>reference count. If you have more than 64K references to a given zval, the
>counter will overflow, then when the references are freed, the object will
>be double-freed, causing a segfault. Dangling references are also possible,
>allowing reading and writing of subsequently allocated blocks.
>
>No doubt the PHP dev team are aware of this already, since it was fixed in
>PHP 5, by using a 32-bit type instead. My question is: is there any
>intention to backport this simple but important bugfix to PHP 4? Many PHP
>users are still using PHP 4, and it's not a very well advertised fact that
>it does not properly support arrays with more than 64K entries.

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).

Zeev