Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66366
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.02.1302281504490.5184@whisky.home.derickrethans.nl>
References: <CAAyV7nGodN0OKUTGY0RQ_P_Za3igkZPXjm1D8r8EUsyZ5XrYeg@mail.gmail.com>
	<alpine.DEB.2.02.1302281504490.5184@whisky.home.derickrethans.nl>
Date: Thu, 28 Feb 2013 16:23:00 -0500
Message-ID: <CAAyV7nE8i2yGo6EhbHVctD=AyuTLgbzM2tmZryVhRG=kN__nag@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec51d2576c6e0ed04d6cf7ea7
Subject: Re: [PHP-DEV] Include XDebug and Suhosin Patch in Core for 5.5
From: ircmaxell@gmail.com (Anthony Ferrara)

--bcaec51d2576c6e0ed04d6cf7ea7
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Derick:

On Thu, Feb 28, 2013 at 3:39 PM, Derick Rethans <derick@php.net> wrote:

> On Thu, 28 Feb 2013, Anthony Ferrara wrote:
>
> > Based off of the recent discussion around pulling in ZO+ into core,
> > I've come to the conclusion that we should also pull in XDebug and
> > Suhosin into core at the same time.
>
> Suhosin has a large performance impact (even the normal patch, without
> turning on anything).
>
> > 3. Both stand as a barrier to adoption as many will not run PHP in
> > development without XDebug
>
> What do you mean?
>
> derick@whisky:~/dev/php/xdebug-xdebug $ TEST_PHP_EXECUTABLE=3D`which php`
> php -dxdebug.auto_trace=3D0 run-tests.php
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> PHP         : /usr/local/php/5.5dev/bin/php
> PHP_SAPI    : cli
> PHP_VERSION : 5.5.0-dev
> ZEND_VERSION: 2.5.0-dev
> PHP_OS      : Linux - Linux whisky 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2
> x86_64
>
> =85
>
> Number of tests :  234               221
> Tests skipped   :   13 (  5.6%) --------
> Tests warned    :    0 (  0.0%) (  0.0%)
> Tests failed    :    0 (  0.0%) (  0.0%)
> Expected fail   :    1 (  0.4%) (  0.5%)
> Tests passed    :  220 ( 94.0%) ( 99.5%)
> ---------------------------------------------------------------------
> Time taken      :   16 seconds
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>

It appears that xdebug is borking generator exception handling.  Without
xdebug the following two tests pass, but with it they fail:

Generator::throw() where the exception is caught in the generator
[Zend/tests/generators/throw_caught.phpt]
Generator::throw() where the generator throws a different exception
[Zend/tests/generators/throw_rethrow.phpt]

And I'm not saying that you're not doing a good job keeping it up. I'm just
saying that it needs to be kept up, so why not put it right in core where
it can be maintained together. The only difference between this and ZO+ in
this case is... Well, there really isn't one. Both opcode caches and
debuggers are WIDELY installed. Both are blockers for upgrading. Both are
supported well (now that ZO+ is open sourced that is). So the drive and
justification for pulling one into core should completely fit the other...

--bcaec51d2576c6e0ed04d6cf7ea7--