Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21442
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Sat, 7 Jan 2006 12:24:39 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <401214529.20060107122439@marcus-boerger.de>
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
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] 16-bit reference count in PHP 4's zval
From: helly@php.net (Marcus Boerger)

Hello Tim,

  that's a major API break so we would need to make that 4.5. Which is kind
of out of question atm. Just change to 5.

marcus

Saturday, January 7, 2006, 5:47:27 AM, you 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 Starling




Best regards,
 Marcus