In the other thread, where Stanislav spreads the usual lie/propaganda
that there is no help comming from me to the PHP developers, he also
claims
For the record - I never said that. I said that in that thread, as
in some of its predecessors, when it came from general discussion to the
substance Stefan somehow lost interest to the substance part. Of course,
he's not in any obligation to contribute to PHP and his substantial help
- when it indeed happens - is always welcome. I just noted in that
particular case it didn't happen, regretfully. Now it happens, which I
can only be glad about.
that the MOPB issues #1 and #2 cannot be fixed right now. Xdebug,
Suhosin, Hardening Patch have already demonstrated for years that it
is not true that #2 [2] cannot be fixed without breaking binary
compatibility.
Actually #1 can't be, as I see it. #2 can, but that requires arbitrarily
limiting stack depth as I far as I can see.
There have also been patches on this mailinglist that calculated the
maximum depth automatically, therefore there is no need to dismantle
this lie.
I don't imagine how one really could calculate maximum depth without
solving the halting problem, so I must be missing something. I ask
somebody who knows what these patches are to send me a link - if there
were patches that do that automatically for any code I would very much
like to see them.
Adding the arbitrary - even configurable - limit doesn't seem to me the
correct solution, since it has high potential to break application code
- with the same effect as the actual bug would. In the context of the
debugger it might be OK since the developer would get immediate feedback
and thus could know what and why crashed, in the context of runtime
application that could be as bad as original bug. Also, since stack size
differs for different OSes, it would be rather hard to find good default
for it. BTW, as far as I can understand, Hardened PHP patch has this
protection disabled by default.
First of all everyone into PHP development knows that the obvious
"fix" for this issue would be to just break binary compatibility and
use a 32 bit reference counter. It does not fix the actual problem
but it is enough so that it cannot be triggered anymore.
Yes, this is correct. However, that would require releasing
binary-incompatible PHP 4 version, which is not supported by the group
as I understand.
However there exists another fix to the problem that deals with the
actual problem of an overflowing reference counter. Therefore every
refcount increase in the Zend Engine Source has to be protected.
While this sounds much of work it actually takes less than half an
hour to do it.
That would also incur considerable performance penalty. As I see in your
patch, you convert a number of increments (which would normally generate
single increment instruction) into function calls. Also, it doesn't
cover extensions accessing refcounts directly (and they do that) - which
is less of a problem, those could be converted too. But performance loss
makes me worry. Did you test the performance difference for the patch?
Even if function calls are converted to a macro, it still might have
some performance lost since refcount change is a very frequent operation
in the engine and inserting a branch for it could hurt performance.
However, if I see somebody showing the patch with near-zero effect it
can be a good case for including such patch.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
