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 wro
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
On Mon, Feb 13, 2012 at 04:38, yoram bar haim 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 f
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 p
Here is a simple test program that reproduce the issue on mac:
lib.h:
#include "lib.h"
void set_index(
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 bu
gt; 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_handl
;
> return SUCCESS;
> }
>
> but it still need dmitry to review :)
>
> thanks
>
> On Sun, Feb 12, 2012 at 8: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 :
> >
try to review :)
>
> thanks
>
> On Sun, Feb 12, 2012 at 8: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'
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_op
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.
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
>
Sorry, problem is not solved yet.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e effects.
> Mike, could you please think about a safer way of fixing.
>
> 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
> >
>
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
ph
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 :
xxx();
} catch (Exception $e) {
}
}
?>
On Monday,
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 suggest
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 cr
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, J
20 matches
Mail list logo
