Hi!
When hacking on Xdebug for PHP 7, I ran into some issues where PHP would
just spin around. This happens when there is an exception, and I use
overloaded opcodes. I wrote a small example extension at
https://github.com/derickr/php-minimal-opcode-overloading-example with a
test case
(https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php)
that shows that something is looping in executing opcodes, as the
HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe this
is a recent enough change, as it only started happening after I upgraded
from about RC1 to latest master.
Would you care to have a look?
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
Hey:
Hi!
When hacking on Xdebug for PHP 7, I ran into some issues where PHP would
just spin around. This happens when there is an exception, and I use
overloaded opcodes. I wrote a small example extension at
https://github.com/derickr/php-minimal-opcode-overloading-example with a
test case
(
https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
)
that shows that something is looping in executing opcodes, as the
HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe this
is a recent enough change, as it only started happening after I upgraded
from about RC1 to latest master.Would you care to have a look?
This is introduced by a fix made by Bob,
https://github.com/php/php-src/commit/808f62bb
Bob, I am going to revert this for now, since you didn't include a test
script to show where the problem was, I am not sure why you made this?
thanks
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
--
Xinchen Hui
@Laruence
http://www.laruence.com/
+bob
Hey:
Hi!
When hacking on Xdebug for PHP 7, I ran into some issues where PHP would
just spin around. This happens when there is an exception, and I use
overloaded opcodes. I wrote a small example extension at
https://github.com/derickr/php-minimal-opcode-overloading-example with a
test case
(
https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
)
that shows that something is looping in executing opcodes, as the
HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe this
is a recent enough change, as it only started happening after I upgraded
from about RC1 to latest master.Would you care to have a look?
This is introduced by a fix made by Bob,
https://github.com/php/php-src/commit/808f62bbBob, I am going to revert this for now, since you didn't include a test
script to show where the problem was, I am not sure why you made this?thanks
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--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Am 20.10.2015 um 17:11 schrieb Xinchen Hui laruence@php.net:
Hey:
Hi!
When hacking on Xdebug for PHP 7, I ran into some issues where PHP would
just spin around. This happens when there is an exception, and I use
overloaded opcodes. I wrote a small example extension at
https://github.com/derickr/php-minimal-opcode-overloading-example with a
test case
(
https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
)
that shows that something is looping in executing opcodes, as the
HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe this
is a recent enough change, as it only started happening after I upgraded
from about RC1 to latest master.Would you care to have a look?
This is introduced by a fix made by Bob,
https://github.com/php/php-src/commit/808f62bb https://github.com/php/php-src/commit/808f62bbBob, I am going to revert this for now, since you didn't include a test
script to show where the problem was, I am not sure why you made this?thanks
cheers,
Derick--
http://derickrethans.nl http://derickrethans.nl/ | http://xdebug.org http://xdebug.org/
Like Xdebug? Consider a donation: http://xdebug.org/donate.php http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine--
Xinchen Hui
@Laruence
http://www.laruence.com/ http://www.laruence.com/
I didn't add any test case as we don't have any APIs in php-src using that user_opcode handler.
I discussed the change back then with Dmitry and committed with his review.
It concretely broke uopz which might throw an exception itself. And in turn we realized that for integrity we need to ensure that opline == EX(opline) else we'll end up with different behavior in global register builds and normal builds.
In general, you should not overload ZEND_HANDLE_EXCEPTION (if you need to, have a special handling for it, but never directly dispatch to it). It is quite special being the only opcode actually allowing EG(exception) to be non-NULL at the start of it.
You are doing an #ifdef ZTS to exempt it… why don't you always exempt it?
Bob
Am 20.10.2015 um 17:11 schrieb Xinchen Hui laruence@php.net:
When hacking on Xdebug for PHP 7, I ran into some issues where PHP
would just spin around. This happens when there is an exception,
and I use overloaded opcodes. I wrote a small example extension at
https://github.com/derickr/php-minimal-opcode-overloading-example
with a test case (
https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
) that shows that something is looping in executing opcodes, as the
HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe
this is a recent enough change, as it only started happening after
I upgraded from about RC1 to latest master.Would you care to have a look?
This is introduced by a fix made by Bob,
https://github.com/php/php-src/commit/808f62bb
https://github.com/php/php-src/commit/808f62bbBob, I am going to revert this for now, since you didn't include a
test script to show where the problem was, I am not sure why you
made this?I didn't add any test case as we don't have any APIs in php-src using
that user_opcode handler. I discussed the change back then with Dmitry
and committed with his review.It concretely broke uopz which might throw an exception itself. And in
turn we realized that for integrity we need to ensure that opline ==
EX(opline) else we'll end up with different behavior in global
register builds and normal builds.In general, you should not overload ZEND_HANDLE_EXCEPTION (if you need
to, have a special handling for it, but never directly dispatch to
it). It is quite special being the only opcode actually allowing
EG(exception) to be non-NULL at the start of it.You are doing an #ifdef ZTS to exempt it… why don't you always exempt
it?
Even if I do (like I've just pushed into the extension), the test still
fails because the code loops. So you did break something.
cheers,
Derick
Am 20.10.2015 um 18:08 schrieb Derick Rethans derick@php.net:
Am 20.10.2015 um 17:11 schrieb Xinchen Hui laruence@php.net:
When hacking on Xdebug for PHP 7, I ran into some issues where PHP
would just spin around. This happens when there is an exception,
and I use overloaded opcodes. I wrote a small example extension at
https://github.com/derickr/php-minimal-opcode-overloading-example
with a test case (
https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
) that shows that something is looping in executing opcodes, as the
HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe
this is a recent enough change, as it only started happening after
I upgraded from about RC1 to latest master.Would you care to have a look?
This is introduced by a fix made by Bob,
https://github.com/php/php-src/commit/808f62bb
https://github.com/php/php-src/commit/808f62bbBob, I am going to revert this for now, since you didn't include a
test script to show where the problem was, I am not sure why you
made this?I didn't add any test case as we don't have any APIs in php-src using
that user_opcode handler. I discussed the change back then with Dmitry
and committed with his review.It concretely broke uopz which might throw an exception itself. And in
turn we realized that for integrity we need to ensure that opline ==
EX(opline) else we'll end up with different behavior in global
register builds and normal builds.In general, you should not overload ZEND_HANDLE_EXCEPTION (if you need
to, have a special handling for it, but never directly dispatch to
it). It is quite special being the only opcode actually allowing
EG(exception) to be non-NULL at the start of it.You are doing an #ifdef ZTS to exempt it… why don't you always exempt
it?Even if I do (like I've just pushed into the extension), the test still
fails because the code loops. So you did break something.cheers,
Derick
Ah, ZEND_CATCH indeed also allows EG(exception) to be non-null…
… maybe I should write
if (EG(exception)
&& opline->opcode != ZEND_HANDLE_EXCEPTION && opline->opcode != ZEND_CATCH
&& ret != ZEND_USER_OPCODE_DISPATCH && ret != ZEND_USER_OPCODE_RETURN && ret != ZEND_USER_OPCODE_ENTER && ret != ZEND_USER_OPCODE_LEAVE) {
HANDLE_EXCEPTION();
}
to allow dispatching for these two opcodes too?
Bob
Am 20.10.2015 um 18:08 schrieb Derick Rethans derick@php.net:
Am 20.10.2015 um 17:11 schrieb Xinchen Hui laruence@php.net:
When hacking on Xdebug for PHP 7, I ran into some issues where
PHP would just spin around. This happens when there is an
exception, and I use overloaded opcodes. I wrote a small example
extension at
https://github.com/derickr/php-minimal-opcode-overloading-example
with a test case (
https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
) that shows that something is looping in executing opcodes, as
the HANDLE_EXCEPTION iirc doesn't advance to the next opline. I
believe this is a recent enough change, as it only started
happening after I upgraded from about RC1 to latest master.Would you care to have a look?
This is introduced by a fix made by Bob,
https://github.com/php/php-src/commit/808f62bb
https://github.com/php/php-src/commit/808f62bbBob, I am going to revert this for now, since you didn't include a
test script to show where the problem was, I am not sure why you
made this?I didn't add any test case as we don't have any APIs in php-src
using that user_opcode handler. I discussed the change back then
with Dmitry and committed with his review.It concretely broke uopz which might throw an exception itself. And
in turn we realized that for integrity we need to ensure that
opline == EX(opline) else we'll end up with different behavior in
global register builds and normal builds.In general, you should not overload ZEND_HANDLE_EXCEPTION (if you
need to, have a special handling for it, but never directly
dispatch to it). It is quite special being the only opcode actually
allowing EG(exception) to be non-NULL at the start of it.You are doing an #ifdef ZTS to exempt it… why don't you always
exempt it?Even if I do (like I've just pushed into the extension), the test
still fails because the code loops. So you did break something.Ah, ZEND_CATCH indeed also allows EG(exception) to be non-null…
… maybe I should write
if (EG(exception)
&& opline->opcode != ZEND_HANDLE_EXCEPTION && opline->opcode != ZEND_CATCH
&& ret != ZEND_USER_OPCODE_DISPATCH && ret != ZEND_USER_OPCODE_RETURN && ret != ZEND_USER_OPCODE_ENTER && ret != ZEND_USER_OPCODE_LEAVE) {
HANDLE_EXCEPTION();
}to allow dispatching for these two opcodes too?
I don't know. Dmitry, Xinchen? I'd like to get this resolved soon..
cheers,
Derick
Hey:
Am 20.10.2015 um 18:08 schrieb Derick Rethans derick@php.net:
Am 20.10.2015 um 17:11 schrieb Xinchen Hui laruence@php.net:
On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans <derick@php.net
mailto:derick@php.net> wrote:When hacking on Xdebug for PHP 7, I ran into some issues where
PHP would just spin around. This happens when there is an
exception, and I use overloaded opcodes. I wrote a small example
extension at
https://github.com/derickr/php-minimal-opcode-overloading-example
with a test case (https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
) that shows that something is looping in executing opcodes, as
the HANDLE_EXCEPTION iirc doesn't advance to the next opline. I
believe this is a recent enough change, as it only started
happening after I upgraded from about RC1 to latest master.Would you care to have a look?
This is introduced by a fix made by Bob,
https://github.com/php/php-src/commit/808f62bb
https://github.com/php/php-src/commit/808f62bbBob, I am going to revert this for now, since you didn't include a
test script to show where the problem was, I am not sure why you
made this?I didn't add any test case as we don't have any APIs in php-src
using that user_opcode handler. I discussed the change back then
with Dmitry and committed with his review.It concretely broke uopz which might throw an exception itself. And
in turn we realized that for integrity we need to ensure that
opline == EX(opline) else we'll end up with different behavior in
global register builds and normal builds.In general, you should not overload ZEND_HANDLE_EXCEPTION (if you
need to, have a special handling for it, but never directly
dispatch to it). It is quite special being the only opcode actually
allowing EG(exception) to be non-NULL at the start of it.You are doing an #ifdef ZTS to exempt it… why don't you always
exempt it?Even if I do (like I've just pushed into the extension), the test
still fails because the code loops. So you did break something.Ah, ZEND_CATCH indeed also allows EG(exception) to be non-null…
… maybe I should write
if (EG(exception)
&& opline->opcode != ZEND_HANDLE_EXCEPTION && opline->opcode !=
ZEND_CATCH
&& ret != ZEND_USER_OPCODE_DISPATCH && ret != ZEND_USER_OPCODE_RETURN
&& ret != ZEND_USER_OPCODE_ENTER && ret != ZEND_USER_OPCODE_LEAVE) {
HANDLE_EXCEPTION();
}to allow dispatching for these two opcodes too?
I don't know. Dmitry, Xinchen? I'd like to get this resolved soon..
The commit which cause this problem has been reverted, so this is
resolved , and regarding the problem which is commit tried to fixed, we
will find a better way to re-fix that.
thanks
cheers,
Derick
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hi,
I'm going to re-fix the problem with the following patch:
https://gist.github.com/dstogov/1eb77a9f2ff7dd807dd1
Thanks. Dmitry.
Hey:
Am 20.10.2015 um 18:08 schrieb Derick Rethans derick@php.net:
Am 20.10.2015 um 17:11 schrieb Xinchen Hui laruence@php.net:
On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans <derick@php.net
mailto:derick@php.net> wrote:When hacking on Xdebug for PHP 7, I ran into some issues where
PHP would just spin around. This happens when there is an
exception, and I use overloaded opcodes. I wrote a small example
extension at
https://github.com/derickr/php-minimal-opcode-overloading-example
with a test case (https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
) that shows that something is looping in executing opcodes, as
the HANDLE_EXCEPTION iirc doesn't advance to the next opline. I
believe this is a recent enough change, as it only started
happening after I upgraded from about RC1 to latest master.Would you care to have a look?
This is introduced by a fix made by Bob,
https://github.com/php/php-src/commit/808f62bb
https://github.com/php/php-src/commit/808f62bbBob, I am going to revert this for now, since you didn't include a
test script to show where the problem was, I am not sure why you
made this?I didn't add any test case as we don't have any APIs in php-src
using that user_opcode handler. I discussed the change back then
with Dmitry and committed with his review.It concretely broke uopz which might throw an exception itself. And
in turn we realized that for integrity we need to ensure that
opline == EX(opline) else we'll end up with different behavior in
global register builds and normal builds.In general, you should not overload ZEND_HANDLE_EXCEPTION (if you
need to, have a special handling for it, but never directly
dispatch to it). It is quite special being the only opcode actually
allowing EG(exception) to be non-NULL at the start of it.You are doing an #ifdef ZTS to exempt it… why don't you always
exempt it?Even if I do (like I've just pushed into the extension), the test
still fails because the code loops. So you did break something.Ah, ZEND_CATCH indeed also allows EG(exception) to be non-null…
… maybe I should write
if (EG(exception)
&& opline->opcode != ZEND_HANDLE_EXCEPTION && opline->opcode !=
ZEND_CATCH
&& ret != ZEND_USER_OPCODE_DISPATCH && ret != ZEND_USER_OPCODE_RETURN
&& ret != ZEND_USER_OPCODE_ENTER && ret != ZEND_USER_OPCODE_LEAVE) {
HANDLE_EXCEPTION();
}to allow dispatching for these two opcodes too?
I don't know. Dmitry, Xinchen? I'd like to get this resolved soon..
The commit which cause this problem has been reverted, so this is
resolved , and regarding the problem which is commit tried to fixed, we
will find a better way to re-fix that.thanks
cheers,
Derick--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hey:
Hi,
I'm going to re-fix the problem with the following patch:
thanks, sorry I was busy last week, plan to do it tonight, but seems you
already fixed it. :)
thanks
Thanks. Dmitry.
Hey:
Am 20.10.2015 um 18:08 schrieb Derick Rethans derick@php.net:
Am 20.10.2015 um 17:11 schrieb Xinchen Hui laruence@php.net:
On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans <derick@php.net
mailto:derick@php.net> wrote:When hacking on Xdebug for PHP 7, I ran into some issues where
PHP would just spin around. This happens when there is an
exception, and I use overloaded opcodes. I wrote a small example
extension at
https://github.com/derickr/php-minimal-opcode-overloading-example
with a test case (https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
) that shows that something is looping in executing opcodes, as
the HANDLE_EXCEPTION iirc doesn't advance to the next opline. I
believe this is a recent enough change, as it only started
happening after I upgraded from about RC1 to latest master.Would you care to have a look?
This is introduced by a fix made by Bob,
https://github.com/php/php-src/commit/808f62bb
https://github.com/php/php-src/commit/808f62bbBob, I am going to revert this for now, since you didn't include a
test script to show where the problem was, I am not sure why you
made this?I didn't add any test case as we don't have any APIs in php-src
using that user_opcode handler. I discussed the change back then
with Dmitry and committed with his review.It concretely broke uopz which might throw an exception itself. And
in turn we realized that for integrity we need to ensure that
opline == EX(opline) else we'll end up with different behavior in
global register builds and normal builds.In general, you should not overload ZEND_HANDLE_EXCEPTION (if you
need to, have a special handling for it, but never directly
dispatch to it). It is quite special being the only opcode actually
allowing EG(exception) to be non-NULL at the start of it.You are doing an #ifdef ZTS to exempt it… why don't you always
exempt it?Even if I do (like I've just pushed into the extension), the test
still fails because the code loops. So you did break something.Ah, ZEND_CATCH indeed also allows EG(exception) to be non-null…
… maybe I should write
if (EG(exception)
&& opline->opcode != ZEND_HANDLE_EXCEPTION && opline->opcode !=
ZEND_CATCH
&& ret != ZEND_USER_OPCODE_DISPATCH && ret != ZEND_USER_OPCODE_RETURN
&& ret != ZEND_USER_OPCODE_ENTER && ret != ZEND_USER_OPCODE_LEAVE) {
HANDLE_EXCEPTION();
}to allow dispatching for these two opcodes too?
I don't know. Dmitry, Xinchen? I'd like to get this resolved soon..
The commit which cause this problem has been reverted, so this is
resolved , and regarding the problem which is commit tried to fixed, we
will find a better way to re-fix that.thanks
cheers,
Derick--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hi Xinchen,
I think, we discussed that patch with Bob, and it looked right.
May be we missed some edge case...
It's not possible to write a test case for it.
Thanks. Dmitry.
Hey:
Hi!
When hacking on Xdebug for PHP 7, I ran into some issues where PHP would
just spin around. This happens when there is an exception, and I use
overloaded opcodes. I wrote a small example extension at
https://github.com/derickr/php-minimal-opcode-overloading-example with a
test case
(
https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
)
that shows that something is looping in executing opcodes, as the
HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe this
is a recent enough change, as it only started happening after I upgraded
from about RC1 to latest master.Would you care to have a look?
This is introduced by a fix made by Bob,
https://github.com/php/php-src/commit/808f62bbBob, I am going to revert this for now, since you didn't include a test
script to show where the problem was, I am not sure why you made this?thanks
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--
Xinchen Hui
@Laruence
http://www.laruence.com/
When hacking on Xdebug for PHP 7, I ran into some issues where PHP
would just spin around. This happens when there is an exception,
and I use overloaded opcodes. I wrote a small example extension at
https://github.com/derickr/php-minimal-opcode-overloading-example
with a test case (
https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
) that shows that something is looping in executing opcodes, as the
HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe
this is a recent enough change, as it only started happening after
I upgraded from about RC1 to latest master.Would you care to have a look?
This is introduced by a fix made by Bob,
https://github.com/php/php-src/commit/808f62bbBob, I am going to revert this for now, since you didn't include a
test script to show where the problem was, I am not sure why you
made this?I think, we discussed that patch with Bob, and it looked right. May be
we missed some edge case...It's not possible to write a test case for it.
I just did ;-) It requires loading this extension though!
In any case, it is causing a bug, and one that ought to be adressed
before the next RC.
cheers,
Derick