Hi Dmitry.
is this improvemnt (intruction reduce and memory read reduce) preserved under
strong compiler optimization (-O2, -O3) ?
is it something that the compiler can not automatically optimize ?
anyhow, the patch seems impressive...
On Monday, December 03, 2012 11:35:52 AM Dmitry Stogov
Please ignore the issue of restart on mac and dlclose. it appears to be a bug
on owr (Zend) side, caused by wrong behavior in extension that increment the
reference count of library.
Sorry for the that.
however, the ability to fully restore the user opcode handler state is still an
issue and is
Please ignore the issue of restart on mac and dlclose. it appears to be a bug
on owr (Zend) side, caused by wrong behavior in extension that increment the
reference count of library.
Sorry for the that.
however, the ability to fully restore the user opcode handler state is still
an issue and is
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
Hi Stas
reproduction is indeed easy - just change a static variable (e.q. call
zend_set_user_opcode_handler()), then send SIGHUP to apache parent process and
check the value in zend_user_opcode_handlers or zend_user_opcodes.
it is possible that this problem is related to specific gcc versions
Here is a simple test program that reproduce the issue on mac:
lib.h:
#include lib.h
void
The last reproduction was executed on darwin 10.8 with gcc 4.2.1
On Monday, February 13, 2012 11:16:41 AM Stas Malyshev wrote:
Hi!
I'm not familiar with Mac, but I saw such behavior on Linux very long
time ago, when on PHP restart static variables were still keep values
from old process.
:
On Mon, Feb 13, 2012 at 04:38, yoram bar haim yora...@zend.com wrote:
Here is a simple test program that reproduce the issue on mac:
[snip]
shell gcc -o lib.so -shared lib.c
shell gcc -o main main.c lib.so
shell ./main
This example is flawed.
The manpage for dlclose(3) on Darwin
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
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
;
}
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
Just to make everything clear, I'm not sure if it was my mistake change 5_4
branch, but currently 5_4 branch (after 322964 commit) solves the header
problem.
Thanks for the work.
On Tue, 31 Jan 2012 10:04:34 +0200, yoram bar haim wrote:
Sorry, problem is not solved yet.
I committed
Sorry, problem is not solved yet.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
The patch to trunk does solve the FastCGI headers problem. tested with PHP
fastcgi on top of lighttpd.
On Tue, 31 Jan 2012 10:04:34 +0200, yoram bar haim wrote:
Sorry, problem is not solved yet.
I committed a possible fix to trunk. It's pretty much along
the patch from you, I just hat
We have the crash in Zend JavaBridge, but yes it will probably occur in .com
eather.
ther scenario is quite simple, you just call a method in a loop. in the
second interation, it will crash.
here is a stenario with JavaBridge :
?php
java_require(dirname(__FILE__) . DIRECTORY_SEPARATOR .
I Debugged the issue described here by lior.
the problem is :
in php_request_shutdown() we call
sapi_send_headers() after
php_output_deactivate().
at this point,
in main/output.c,
OG(flags) PHP_OUTPUT_ACTIVATED is false so
php_output_write_unbuffered() calls
.
Thanks. Dmitry.
On 01/30/2012 07:29 PM, yoram bar haim wrote:
I Debugged the issue described here by lior.
the problem is :
in php_request_shutdown() we call
sapi_send_headers() after
php_output_deactivate().
at this point,
in main/output.c,
OG(flags
in zend_vm_execute.h:701 PHP free's the function struct in case of
ZEND_OVERLOADED_FUNCTION. the problem is that in PHP 5.4, the opline calling
the function hast a pointer to the very same struct in it's cache_slot. when
this opcode is called againg, the cache is used and it crashes.
my
the main difference is php_sprintf
in 5.3 it calls OG(php_body_write) which points to php_default_output_func at
tha point.
in 5.4 it calls php_output_write, which writes output via SAPI.
On Wednesday, January 25, 2012 05:07:15 PM Dmitry Stogov wrote:
Hi Stas,
We've just found one more
If we want __CLASS__ to be resolved at runtime (at list in case of trait),
then what about __FILE__ and __LINE__ ? should they be resolved at compile
time and reflect the original code in the trait or should they reffer to the
using class (which is a problem for the __LINE__ ...) ?
On Monday,
20 matches
Mail list logo
