[PHP-DEV] restore user opcode handler in PHP
I first saw this problem while addapting extension to PHP 5.4 but the code is the same in 5.3 : when you call zend_set_user_opcode_handler() it set's a pointer (handler) in zend_user_opcode_handlers and a uint opcode value in zend_user_opcodes to ZEND_USER_OPCODE . you can call zend_set_user_opcode_handler with the original handler to restore it, but if the original state did not include ZEND_USER_OPCODE you have no way to restore it. Why restoring ? On mac, static variables are not re-initialized on dlclose()+dlopen(). that means that apache reload does not re-create zend_user_opcode_handlers and zend_user_opcodes. if your extension sets user_opcode_handler and is not reloaded in apache reload (because you commented it in php.ini, for example), your handlers array will actually point to non-exist handler. if you will call zend_set_user_opcode_handler() with the original handler at MSHUTDOWN, it will restore the handler but zend_user_opcodes[opcode] will still be ZEND_USER_OPCODE so you will end up calling a NULL handler. we should eather allow zend_set_user_opcode_handler to also set the value in zend_user_opcodes[opcode] or we should build those arrayes from scratch at php_module_init. currently an extension tha calls zend_set_user_opcode_handler() will make PHP crash on mac after disabling the extension and apache reload. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] restore user opcode handler in PHP
Hi:
could you file a feature req on bugs.php.net?
I think it's okey to add a zend_restore_user_handler .
like:
ZEND_API int zend_restore_user_opcode_handler(zend_uchar opcode) {
zend_user_opcodes[opcode] = opcode;
zend_user_opcode_handlers[opcode] = NULL;
return SUCCESS;
}
but it still need dmitry to review :)
thanks
On Sun, Feb 12, 2012 at 8:09 PM, yoram bar haim yora...@zend.com wrote:
I first saw this problem while addapting extension to PHP 5.4 but the code is
the same in 5.3 :
when you call zend_set_user_opcode_handler() it set's a pointer (handler) in
zend_user_opcode_handlers and a uint opcode value in zend_user_opcodes to
ZEND_USER_OPCODE .
you can call zend_set_user_opcode_handler with the original handler to restore
it, but if the original state did not include ZEND_USER_OPCODE you have no way
to restore it.
Why restoring ?
On mac, static variables are not re-initialized on dlclose()+dlopen(). that
means that apache reload does not re-create zend_user_opcode_handlers and
zend_user_opcodes.
if your extension sets user_opcode_handler and is not reloaded in apache
reload (because you commented it in php.ini, for example), your handlers array
will actually point to non-exist handler.
if you will call zend_set_user_opcode_handler() with the original handler at
MSHUTDOWN, it will restore the handler but zend_user_opcodes[opcode] will
still be ZEND_USER_OPCODE so you will end up calling a NULL handler.
we should eather allow zend_set_user_opcode_handler to also set the value in
zend_user_opcodes[opcode] or we should build those arrayes from scratch at
php_module_init.
currently an extension tha calls zend_set_user_opcode_handler() will make PHP
crash on mac after disabling the extension and apache reload.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] restore user opcode handler in PHP
I think the following patch is a better solution, currently trying it :
--- Zend/zend_execute.c.orig2012-02-12 14:32:07.0 +0200
+++ Zend/zend_execute.c 2012-02-12 14:31:33.0 +0200
@@ -1512,7 +1512,11 @@
ZEND_API int zend_set_user_opcode_handler(zend_uchar opcode,
user_opcode_handler_t handler)
{
if (opcode != ZEND_USER_OPCODE) {
- zend_user_opcodes[opcode] = ZEND_USER_OPCODE;
+ if (handler == NULL) {
+ zend_user_opcodes[opcode] = opcode;
+ } else {
+ zend_user_opcodes[opcode] = ZEND_USER_OPCODE;
+ }
zend_user_opcode_handlers[opcode] = handler;
return SUCCESS;
}
On Sunday, February 12, 2012 02:41:44 PM Laruence wrote:
Hi:
could you file a feature req on bugs.php.net?
I think it's okey to add a zend_restore_user_handler .
like:
ZEND_API int zend_restore_user_opcode_handler(zend_uchar opcode) {
zend_user_opcodes[opcode] = opcode;
zend_user_opcode_handlers[opcode] = NULL;
return SUCCESS;
}
but it still need dmitry to review :)
thanks
On Sun, Feb 12, 2012 at 8:09 PM, yoram bar haim yora...@zend.com wrote:
I first saw this problem while addapting extension to PHP 5.4 but the
code is the same in 5.3 :
when you call zend_set_user_opcode_handler() it set's a pointer (handler)
in zend_user_opcode_handlers and a uint opcode value in
zend_user_opcodes to ZEND_USER_OPCODE .
you can call zend_set_user_opcode_handler with the original handler to
restore it, but if the original state did not include ZEND_USER_OPCODE
you have no way to restore it.
Why restoring ?
On mac, static variables are not re-initialized on dlclose()+dlopen().
that means that apache reload does not re-create
zend_user_opcode_handlers and zend_user_opcodes.
if your extension sets user_opcode_handler and is not reloaded in apache
reload (because you commented it in php.ini, for example), your handlers
array will actually point to non-exist handler.
if you will call zend_set_user_opcode_handler() with the original handler
at MSHUTDOWN, it will restore the handler but zend_user_opcodes[opcode]
will still be ZEND_USER_OPCODE so you will end up calling a NULL
handler.
we should eather allow zend_set_user_opcode_handler to also set the value
in zend_user_opcodes[opcode] or we should build those arrayes from
scratch at php_module_init.
currently an extension tha calls zend_set_user_opcode_handler() will make
PHP crash on mac after disabling the extension and apache reload.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] restore user opcode handler in PHP
The attatched patch solves the problem and I think it is more robust then
adding a new function.
calling a function like the proposed zend_restore_user_opcode_handler() might
be a problem in case someone else put handler before you.
instead of that it's easier to just tell zend_set_user_opcode_handler() to
restore the opcode value in case the handler is NULL.
that will make the flow of zend_set_user_opcode_handler(my_handler) and then
zend_set_user_opcode_handler(orig_handler) simpler.
a patch is attatched and tested.
On Sunday, February 12, 2012 02:41:44 PM Laruence wrote:
Hi:
could you file a feature req on bugs.php.net?
I think it's okey to add a zend_restore_user_handler .
like:
ZEND_API int zend_restore_user_opcode_handler(zend_uchar opcode) {
zend_user_opcodes[opcode] = opcode;
zend_user_opcode_handlers[opcode] = NULL;
return SUCCESS;
}
but it still need dmitry to review :)
thanks
On Sun, Feb 12, 2012 at 8:09 PM, yoram bar haim yora...@zend.com wrote:
I first saw this problem while addapting extension to PHP 5.4 but the
code is the same in 5.3 :
when you call zend_set_user_opcode_handler() it set's a pointer (handler)
in zend_user_opcode_handlers and a uint opcode value in
zend_user_opcodes to ZEND_USER_OPCODE .
you can call zend_set_user_opcode_handler with the original handler to
restore it, but if the original state did not include ZEND_USER_OPCODE
you have no way to restore it.
Why restoring ?
On mac, static variables are not re-initialized on dlclose()+dlopen().
that means that apache reload does not re-create
zend_user_opcode_handlers and zend_user_opcodes.
if your extension sets user_opcode_handler and is not reloaded in apache
reload (because you commented it in php.ini, for example), your handlers
array will actually point to non-exist handler.
if you will call zend_set_user_opcode_handler() with the original handler
at MSHUTDOWN, it will restore the handler but zend_user_opcodes[opcode]
will still be ZEND_USER_OPCODE so you will end up calling a NULL
handler.
we should eather allow zend_set_user_opcode_handler to also set the value
in zend_user_opcodes[opcode] or we should build those arrayes from
scratch at php_module_init.
currently an extension tha calls zend_set_user_opcode_handler() will make
PHP crash on mac after disabling the extension and apache reload.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--- Zend/zend_execute.c.orig 2012-02-12 14:32:07.0 +0200
+++ Zend/zend_execute.c 2012-02-12 14:31:33.0 +0200
@@ -1512,7 +1512,11 @@
ZEND_API int zend_set_user_opcode_handler(zend_uchar opcode, user_opcode_handler_t handler)
{
if (opcode != ZEND_USER_OPCODE) {
- zend_user_opcodes[opcode] = ZEND_USER_OPCODE;
+ if (handler == NULL) {
+ zend_user_opcodes[opcode] = opcode;
+ } else {
+ zend_user_opcodes[opcode] = ZEND_USER_OPCODE;
+ }
zend_user_opcode_handlers[opcode] = handler;
return SUCCESS;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #61033 __FUNCTION__ doesn't report correctly in alias trait methods
On Fri 10 Feb 2012 09:49:54 GMT, Stefan Marr wrote: Hi Marc: On 09 Feb 2012, at 22:36, Marc Easen wrote: The reason why I feel this should be changes to reflect the actual called function name is that one of main uses of the __FUNCTION__ constant it to refer back to the function that is currently running, for the use recursive functions: I still maintain the position that __FUNCTION__, as __LINE__ and __FILE__, is supposed to be a lexical constant. (In retro-spective, adapting __CLASS__ to do even more magic might have been a mistake, from a conceptual point of view.) As with PHP 5.4 you are able change the function name and the class you are running in thanks to traits, so makes sense to update these magic constants to represent the the value at run time as apposed to compile time. __LINE__ and __FILE__ will always be relating to values at compile time. Cheers, Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Deprecate and remove /e modifier from preg_replace
As there doesn't seem to be any further discussion regarding this issue I have opened the vote: https://wiki.php.net/rfc/remove_preg_replace_eval_modifier#vote Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: restore user opcode handler in PHP
Hi Yoram, Can we just fill this arrays with zeros on php startup? Thanks. Dmitry. On 02/12/2012 04:09 PM, yoram bar haim wrote: I first saw this problem while addapting extension to PHP 5.4 but the code is the same in 5.3 : when you call zend_set_user_opcode_handler() it set's a pointer (handler) in zend_user_opcode_handlers and a uint opcode value in zend_user_opcodes to ZEND_USER_OPCODE . you can call zend_set_user_opcode_handler with the original handler to restore it, but if the original state did not include ZEND_USER_OPCODE you have no way to restore it. Why restoring ? On mac, static variables are not re-initialized on dlclose()+dlopen(). that means that apache reload does not re-create zend_user_opcode_handlers and zend_user_opcodes. if your extension sets user_opcode_handler and is not reloaded in apache reload (because you commented it in php.ini, for example), your handlers array will actually point to non-exist handler. if you will call zend_set_user_opcode_handler() with the original handler at MSHUTDOWN, it will restore the handler but zend_user_opcodes[opcode] will still be ZEND_USER_OPCODE so you will end up calling a NULL handler. we should eather allow zend_set_user_opcode_handler to also set the value in zend_user_opcodes[opcode] or we should build those arrayes from scratch at php_module_init. currently an extension tha calls zend_set_user_opcode_handler() will make PHP crash on mac after disabling the extension and apache reload. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] restore user opcode handler in PHP
In case this patch works, I think it's fine to include it.
Thanks. Dmitry.
On 02/12/2012 04:55 PM, yoram bar haim wrote:
I think the following patch is a better solution, currently trying it :
--- Zend/zend_execute.c.orig2012-02-12 14:32:07.0 +0200
+++ Zend/zend_execute.c 2012-02-12 14:31:33.0 +0200
@@ -1512,7 +1512,11 @@
ZEND_API int zend_set_user_opcode_handler(zend_uchar opcode,
user_opcode_handler_t handler)
{
if (opcode != ZEND_USER_OPCODE) {
- zend_user_opcodes[opcode] = ZEND_USER_OPCODE;
+ if (handler == NULL) {
+ zend_user_opcodes[opcode] = opcode;
+ } else {
+ zend_user_opcodes[opcode] = ZEND_USER_OPCODE;
+ }
zend_user_opcode_handlers[opcode] = handler;
return SUCCESS;
}
On Sunday, February 12, 2012 02:41:44 PM Laruence wrote:
Hi:
could you file a feature req on bugs.php.net?
I think it's okey to add a zend_restore_user_handler .
like:
ZEND_API int zend_restore_user_opcode_handler(zend_uchar opcode) {
zend_user_opcodes[opcode] = opcode;
zend_user_opcode_handlers[opcode] = NULL;
return SUCCESS;
}
but it still need dmitry to review :)
thanks
On Sun, Feb 12, 2012 at 8:09 PM, yoram bar haimyora...@zend.com wrote:
I first saw this problem while addapting extension to PHP 5.4 but the
code is the same in 5.3 :
when you call zend_set_user_opcode_handler() it set's a pointer (handler)
in zend_user_opcode_handlers and a uint opcode value in
zend_user_opcodes to ZEND_USER_OPCODE .
you can call zend_set_user_opcode_handler with the original handler to
restore it, but if the original state did not include ZEND_USER_OPCODE
you have no way to restore it.
Why restoring ?
On mac, static variables are not re-initialized on dlclose()+dlopen().
that means that apache reload does not re-create
zend_user_opcode_handlers and zend_user_opcodes.
if your extension sets user_opcode_handler and is not reloaded in apache
reload (because you commented it in php.ini, for example), your handlers
array will actually point to non-exist handler.
if you will call zend_set_user_opcode_handler() with the original handler
at MSHUTDOWN, it will restore the handler but zend_user_opcodes[opcode]
will still be ZEND_USER_OPCODE so you will end up calling a NULL
handler.
we should eather allow zend_set_user_opcode_handler to also set the value
in zend_user_opcodes[opcode] or we should build those arrayes from
scratch at php_module_init.
currently an extension tha calls zend_set_user_opcode_handler() will make
PHP crash on mac after disabling the extension and apache reload.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
