Hey all,
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.
-
It has integration issues with ZO+ in that it has to be included in a
specific order (specifically around ini declarations). If it was included
into core, this could be accounted for allowing for more robust behavior. -
Both to be maintained for each new language feature as well as
opcode-caches. This will have the same benefit as integrating ZO+, as it
can be maintained inline with the engine. -
Both stand as a barrier to adoption as many will not run PHP in
development without XDebug, and they won't run it in production without the
Suhosin patch.
Since both of these are vital to PHP's uptake and adoption of new versions,
I feel it's important to delay 5.5 until we can get both in. I can draft up
the RFC if necessary...
Anthony
Hi!
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 multiple BC-incompatible and performance-problematic changes
and limits and the author refused many times to work with PHP team. I'm
not sure how we could pull extension that the author of it isn't
interested in working with PHP group.
- It has integration issues with ZO+ in that it has to be included in a
specific order (specifically around ini declarations). If it was included
into core, this could be accounted for allowing for more robust behavior.
I'm not sure what you mean about ini declarations, could you expand on
this or refer me to the place where it is explained?
- Both to be maintained for each new language feature as well as
opcode-caches. This will have the same benefit as integrating ZO+, as it
can be maintained inline with the engine.
I'm not sure how it's different than any other extension. If API
changes, they need to change for every version. Also, are you sure
either of the maintainers actually wants to be part of PHP release
cycle? At least for Suhosin we know it's actually not the case.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Thu, Feb 28, 2013 at 9:13 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
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 multiple BC-incompatible and performance-problematic changes
and limits and the author refused many times to work with PHP team. I'm
not sure how we could pull extension that the author of it isn't
interested in working with PHP group.
+1
- It has integration issues with ZO+ in that it has to be included in a
specific order (specifically around ini declarations). If it was included
into core, this could be accounted for allowing for more robust behavior.I'm not sure what you mean about ini declarations, could you expand on
this or refer me to the place where it is explained?
I guess the ini declaration order and then the order the modules get loaded
in the engine.
Julien
Hi
2013/3/1 Julien Pauli jpauli@php.net:
I guess the ini declaration order and then the order the modules get loaded
in the engine.
We could also look at implementing a module-load-order internally in
the zend_module struct, as in some extensions like EXIF relies on
mbstring, while the ZEND_MODULE_DEP()s works fine for checking for
mbstring, it does not work if mbstring is loaded after. So what I'm
saying is that mbstring have a higher load order, meaning even though
we have this in php.ini1, PHP will load mbstring first because it
has the lowest value (requiring it to start first), or giving exif a
higher than 'normal' value (causing it to load after, as it is after
all, exif that depends on mbstring, not the other way around).
The same thing can be done with engine level extensions
(zend_extension), where it probably would make more sense than for 90%
of all 'php' extensions.
extension=php_mbstring.dll
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hi
2013/3/1 Julien Pauli jpauli@php.net:
I guess the ini declaration order and then the order the modules get
loaded
in the engine.We could also look at implementing a module-load-order internally in
the zend_module struct, as in some extensions like EXIF relies on
mbstring, while the ZEND_MODULE_DEP()s works fine for checking for
mbstring, it does not work if mbstring is loaded after. So what I'm
saying is that mbstring have a higher load order, meaning even though
we have this in php.ini1, PHP will load mbstring first because it
has the lowest value (requiring it to start first), or giving exif a
higher than 'normal' value (causing it to load after, as it is after
all, exif that depends on mbstring, not the other way around).The same thing can be done with engine level extensions
(zend_extension), where it probably would make more sense than for 90%
of all 'php' extensions.extension=php_mbstring.dll
+1 , Some time ago when I first designed my first extensions studying the
Zend extension loading mechanism I thought about such a system and was
surprised not to find one into the engine.
It shouldn't be too hard to develop, except if you start thinking about
versions dependencies of the modules as well.
In the same pipe, I was thinking at some dlunload() function which would
enable unoloading modules at runtime, but that's another task, not very
trivial though.
Julien
--
regards,Kalle Sommer Nielsen
kalle@php.net
I agree with adding XDebug to core distribution but it must be disabled by
default.
On Fri, Mar 1, 2013 at 12:49 PM, Kalle Sommer Nielsen kalle@php.net
wrote:Hi
2013/3/1 Julien Pauli jpauli@php.net:
I guess the ini declaration order and then the order the modules get
loaded
in the engine.We could also look at implementing a module-load-order internally in
the zend_module struct, as in some extensions like EXIF relies on
mbstring, while the ZEND_MODULE_DEP()s works fine for checking for
mbstring, it does not work if mbstring is loaded after. So what I'm
saying is that mbstring have a higher load order, meaning even though
we have this in php.ini1, PHP will load mbstring first because it
has the lowest value (requiring it to start first), or giving exif a
higher than 'normal' value (causing it to load after, as it is after
all, exif that depends on mbstring, not the other way around).The same thing can be done with engine level extensions
(zend_extension), where it probably would make more sense than for 90%
of all 'php' extensions.extension=php_mbstring.dll
+1 , Some time ago when I first designed my first extensions studying the
Zend extension loading mechanism I thought about such a system and was
surprised not to find one into the engine.
It shouldn't be too hard to develop, except if you start thinking about
versions dependencies of the modules as well.In the same pipe, I was thinking at some dlunload() function which would
enable unoloading modules at runtime, but that's another task, not very
trivial though.Julien
--
regards,Kalle Sommer Nielsen
kalle@php.net
[...]
Sorry, but I hope you are in some funny sort of mood...
Mike
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).
- 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=which php php -dxdebug.auto_trace=0 run-tests.php
=====================================================================
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
…
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
cheers,
Derick
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
Derick:
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).
- Both stand as a barrier to adoption as many will not run PHP in
development without XDebugWhat do you mean?
derick@whisky:~/dev/php/xdebug-xdebug $ TEST_PHP_EXECUTABLE=
which php
php -dxdebug.auto_trace=0 run-tests.php=====================================================================
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…
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
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...
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]
I guess that's because something hijacks the throw exception handler,
it's the samething with SOAP. This should be addressed so that there is
a chain/set of handlers instead.
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...
I don't want it.
cheers,
Derick
- It has integration issues with ZO+ in that it has to be included in a
specific order (specifically around ini declarations). If it was included
into core, this could be accounted for allowing for more robust behavior.
I don't use Suhoshin, nor do I want to (not that it is bad, I just
don't want the performance hit.) Additionally, I like to set up a
development environment with XDebug, and I like to leave XDebug out of
my production environment.
- Both to be maintained for each new language feature as well as
opcode-caches. This will have the same benefit as integrating ZO+, as it
can be maintained inline with the engine.
Derrick is doing a great job keeping XDebug up-to-date, so why does
this need to change. In contrast, APC was having a very difficult time
keeping up.
- Both stand as a barrier to adoption as many will not run PHP in
development without XDebug, and they won't run it in production without the
Suhosin patch.
Many won't run WITH Sohosin in production.
In terms of XDebug and opcode caches, I really do believe there is a
big difference between the two in terms of the severity of bugs. A bug
in XDebug is not as critical to me, as I can live with and work around
XDebug issues (what few I've encountered) because I experience these
in dev environments. However, an opcode cache is a production
environment feature, which makes these bugs much more severe in
nature.
Adam
Hey all,
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.
It has integration issues with ZO+ in that it has to be included in a
specific order (specifically around ini declarations). If it was included
into core, this could be accounted for allowing for more robust behavior.Both to be maintained for each new language feature as well as
opcode-caches. This will have the same benefit as integrating ZO+, as it
can be maintained inline with the engine.Both stand as a barrier to adoption as many will not run PHP in
development without XDebug, and they won't run it in production without the
Suhosin patch.Since both of these are vital to PHP's uptake and adoption of new versions,
I feel it's important to delay 5.5 until we can get both in. I can draft up
the RFC if necessary...Anthony
Nice :-P
Seriously though, what's the deal with the Suhosin patch? I use it because it's included by default on Ubuntu... Didn't know about the huge performance impact. Their website seems to imply that PHP has security holes that have never been patched, and are only closed by using Suhosin. I find that hard to believe. Is PHP really that vulnerable without it? The site (http://www.hardened-php.net/suhosin/) is somewhat light on details.
Cheers,
David
Hey all,
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.
It has integration issues with ZO+ in that it has to be included in a
specific order (specifically around ini declarations). If it was included
into core, this could be accounted for allowing for more robust behavior.Both to be maintained for each new language feature as well as
opcode-caches. This will have the same benefit as integrating ZO+, as it
can be maintained inline with the engine.Both stand as a barrier to adoption as many will not run PHP in
development without XDebug, and they won't run it in production without
the
Suhosin patch.Since both of these are vital to PHP's uptake and adoption of new
versions,
I feel it's important to delay 5.5 until we can get both in. I can draft
up
the RFC if necessary...Anthony
Nice :-P
Seriously though, what's the deal with the Suhosin patch? I use it because
it's included by default on Ubuntu... Didn't know about the huge
performance impact. Their website seems to imply that PHP has security
holes that have never been patched, and are only closed by using Suhosin. I
find that hard to believe. Is PHP really that vulnerable without it? The
site (http://www.hardened-php.net/suhosin/) is somewhat light on details.
Any computer system is vulnerable as far as you press the start button and
plug in the network cable ;-)
Julien