Hey: On Mon, Oct 26, 2015 at 8:11 PM, Dmitry Stogov <dmi...@zend.com> wrote:
> Hi, > > I'm going to re-fix the problem with the following patch: > > https://gist.github.com/dstogov/1eb77a9f2ff7dd807dd1 > thanks, sorry I was busy last week, plan to do it tonight, but seems you already fixed it. :) thanks > > > Thanks. Dmitry. > > On Thu, Oct 22, 2015 at 5:43 AM, Xinchen Hui <larue...@php.net> wrote: > >> Hey: >> >> >> >> On Wed, Oct 21, 2015 at 10:38 PM, Derick Rethans <der...@php.net> wrote: >> >>> On Tue, 20 Oct 2015, Bob Weinand wrote: >>> >>> > > Am 20.10.2015 um 18:08 schrieb Derick Rethans <der...@php.net>: >>> > > >>> > > On Tue, 20 Oct 2015, Bob Weinand wrote: >>> > > >>> > >>> Am 20.10.2015 um 17:11 schrieb Xinchen Hui <larue...@php.net>: >>> > >>> >>> > >>> On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans <der...@php.net >>> <mailto:der...@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/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? >>> > >> >>> > >> 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/
