Re: [PHP-DEV] Re: Please reconsider supporting PHP 5.2

[Olivier B.]

Le 25/07/2010 17:15, Kalle Sommer Nielsen a écrit :

Hello

2010/7/25 Karoly Negyesi:'
   

Extensions. APC to this day does not have a stable release for PHP
5.3. Neither has XCache. I am not even sure how do you imagine
*anyone* much less everyone upgrading to 5.3 with a production site
without a stable code cache...?
 


You should check your sources better regarding APC, have a look at the
APC 3.1.3:
http://pecl.php.net/package-info.php?package=APC&version=3.1.3

Even before 5.3.0 was released, we worked on making APC compatible
with 5.3 which was released only 1 month and 2 weeks after the
release. Even the next release of APC thats going beta soon is having
full support for the latest development branch (5.3.99).

   
APC 3.1.x is marked as "beta", not "stable" : 
http://pecl.php.net/package/APC

Maybe it's time to mark it as "stable", if it's the case.

Olivier

Re: [PHP-DEV] Performance problem with php

[Olivier B.]

Hi,

are you using the "suhosin" patch for PHP ? I can see the same lstat 
behaviour with my setups, because of suhosin.
But for the 8 tentative of reading, are you sure php deliver only one 
page here ?


Olivier

Le 20/06/2010 08:49, Vincenzo D'Amore a écrit :

Hello,

to have a performance problem with apache/mod_php5 configuration under heavy
load the website becomes too slow.
Using strace I found what appears to me a strange behavior
The strange behavior I want point out is related to a sequence of tentative
httpd/mod_php5 does in order to read an php page.

In this particular case apache httpd servers tries 8 times before reach and
read the file (if you want I can send the complete strace output)
More strange all these tentative seems to be correctly completed because of
success (0) return code for each line.
Ffor every file should be served by apache httpd, apache httpd tries to
lstat all directory in path more times:

lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/local", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/local/sitipersonali", {st_mode=S_IFDIR|0755, st_size=4096, ...})
= 0
lstat("/usr/local/sitipersonali/sitipersonali08", {st_mode=S_IFDIR|0777,
st_size=1024, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP", {st_mode=S_IFDIR|0755,
st_size=13312, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa",
{st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al",
{st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps",
{st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs",
{st_mode=S_IFDIR|0755, st_size=2048, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content",
{st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content/languages",
{st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content/languages/zh_CN.php",
{st_mode=S_IFREG|0777, st_size=1312, ...}) = 0

*FIRST TENTATIVE*

lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/local", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/local/sitipersonali", {st_mode=S_IFDIR|0755, st_size=4096, ...})
= 0
lstat("/usr/local/sitipersonali/sitipersonali08", {st_mode=S_IFDIR|0777,
st_size=1024, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP", {st_mode=S_IFDIR|0755,
st_size=13312, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa",
{st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al",
{st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps",
{st_mode=S_IFDIR|0750, st_size=1024, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451",
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs",
{st_mode=S_IFDIR|0755, st_size=2048, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content",
{st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content/languages",
{st_mode=S_IFDIR|0777, st_size=1024, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa/al/wall/webspace/siteapps/21451/htdocs/wp-content/languages/zh_CN.php",
{st_mode=S_IFREG|0777, st_size=1312, ...}) = 0

*SECOND*

  lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/local", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/local/sitipersonali", {st_mode=S_IFDIR|0755, st_size=4096, ...})
= 0
lstat("/usr/local/sitipersonali/sitipersonali08", {st_mode=S_IFDIR|0777,
st_size=1024, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP", {st_mode=S_IFDIR|0755,
st_size=13312, ...}) = 0
lstat("/usr/local/sitipersonali/sitipersonali08/NSP/wa",
{st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
lstat("/usr/local

Re: [PHP-DEV] [PATCH] Raise warning first on "Maximum execution time exceeded"

[Olivier B.]

Hi,

well, maybe we should provide a better behaviour for all fatal errors, no ?
A frequent one I see is the fatal error for calls like "$obj->method()", 
when $obj is not an object.


Isn't possible to allow catching of fatal errors, like other errors ?

Olivier

On 22/03/2010 15:51, troels knak-nielsen wrote:

Hi list.

We log all errors that happens in our production environment, but as
fatal errors can't be handled from within php, we end up with little
information to go on for further debugging. I'm not very familiar with
the php internals code, but I managed to throw in a hack that appears
to work. In the handler function for timeouts (zend_timeout), I raise
a WARNING, sleep for 1 second and then resume normal behavior, which
results in a fatal error. This gives userland code 1 second to log the
error somewhere, which should be sufficient for debugging.

Would like to get feedback as to if this has any hidden problems, but
otherwise I propose that it's included in the project.

   



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Throwing an E_DEPRECATED for short_open_tag

[Olivier B.]

Hi,

and why Debian still use the php module version by default ?
By using the fcgi version each application can have it's own php.ini.

Furthermore, it's a different problem but this will also allow use of a 
specific unix account for each apps.

In the actual Debian's php.ini we can found about safe_mode :
> NOTE: this is considered a "broken" security measure. Applications 
relying on this feature will not recieve full support by the security 
team.  For more information please see 
/usr/share/doc/php5-common/README.Debian.security
I agree with that, but there is no security at all on default Debian 
install : any PHP application can read configuration (DB passwords, 
encryption keys, etc) of other PHP applications.


As a Debian user, I always modify the default behaviour to have 
phpmyadmin running under the "phpmyadmin" account and using my 
/etc/phpmyadmin/php.ini file. Same problem with roundcube too, and other 
apps.


So, maybe Debian should change if way of deploying PHP apps, to allow 
better security and per-apps config file, no ?


In any case, I really really don't want PHP throw an E_DEPRECATED on 
apps using short_open_tag.


Olivier

Derick Rethans a écrit :

On Tue, 12 Jan 2010, Raphael Geissert wrote:

  
As mentioned on my other post, at Debian we are planning to include 
5.3 in Squeeze. Given that the development and production php.ini 
files both turn short_open_tag by default but many applications 
shipped by Debian itself still require it to be enabled, we have 
decided to _enable_ it again on the .ini files.



Would it be possible to force short_open_tag to a specific value for 
those applications alone? Perhaps through an .htaccess file? That way, 
Debian keeps the "PHP default" but still allows those apps to work.


  
However, we would like to contribute in the quest to make applications 
stop using short_open_tag. To do so, we have decided to throw an 
E_DEPRECATED warning when an application makes use of short_open_tag. 
The current implementation can be found at [1].


How does this sound?



Like Rasmus said, we've no intention of deprecating it. It's just that 
apps requiring short open tags are not really portable (because they 
don't work when short_open_tag is set to 0).


with kind regards,
Derick

  


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Why is ereg being deprecated?

[Olivier B.]

Christian Schneider a écrit :

Mark Krenz wrote:
  

  But I'm willing to bet that the majority of people are using ereg, not
PCRE.  I've known about PCRE in PHP for a while now, but I continue to
use ereg because I thought it had better support in PHP and that it was
the more "official" function. Guess I was wrong.  I'm sure I'm not the



I guess that's exactly the reason why it is deprecated now: To indicate
that preg_* are the way to go.
And as far as I know, using ereg_* function is discouraged in the 
documentation since PHP 4, 10 years ago, no ?



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Configuration in the php.ini file

[Olivier B.]

Hi


There isn't because nobody developed that or because it is contradicted ?

here we extends the PDO class to configure it like we want.
For example :
class ourPDO
{
   public function __construct( $dsn, $user = NULL, $password = NULL, 
$options = NULL )

   {
   $defaultOptions = array(
   PDO::ATTR_ERRMODE => PDO::ERRMODE_WARNING,
   PDO::ATTR_TIMEOUT => 5,
   PDO::ATTR_CASE => PDO::CASE_NATURAL,
   PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
   );

   if( is_array($options) )
   $defaultOptions = $options + $defaultOptions;

   parent::__construct($dsn, $user, $password, $defaultOptions);
   }
}

and in code, we use $db = new ourPDO( ... );


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] set_magic_quotes_runtime is still E_DEPRECATED

[Olivier B.]

Hannes Magnusson a écrit :

On Tue, Jun 16, 2009 at 10:09, Pierre Joye wrote:
  

hi,

On Tue, Jun 16, 2009 at 9:46 AM, Lukas Kahwe Smith wrote:


On 16.06.2009, at 05:08, Greg Beaver wrote:

  

Hi,

in PHP_5_3 if you're using set_magic_quotes_runtime(0), it raises an
E_DEPRECATED.  I thought all that argument was resolved to only throw
E_DEPRECATED for set_magic_quotes_runtime(1)?

This is a major pain if magic_quotes are enabled and you need to turn
them off to do unserialize or serialize to a file.


I think it makes sense to keep the deprecate warning for the setter.




Even to disable MQ runtime?
I don't know.. Since MQ is deprecated why are we throwing warnings
when people are trying to turn it off?

-Hannes

  
Because in PHP 6 (or next) the function "set_magic_quotes_runtime()" 
will be removed, so calling it without checking ini_get() will trigger a 
fatal error, no ?


Olivier


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] APM

[Olivier B.]

Hi,

why not use reporting thought syslog ? It's standard and "central 
aggregation" is already available (thought TCP or databases).


Olivier

Patrick ALLAERT a écrit :

Hi list,

First, I'd like to apologize if the subject of this mail is somewhat off-topic.

Davide Mendolia and me are currently working on: "Alternative PHP
Monitor" (APM - http://code.google.com/p/peclapm/) which consist of
three parts:
- a PHP extension which has as a goal of capturing "events" (warning,
error, notices,... and slow requests) storing them centrally in an
SQLite DB.
- a webfrontend to display captured events (for now, it's basically a
table without any filtering or querying).
- a "central aggregator" which collects events from the different
"nodes" (still not developped).

I think it is important to mention that we are talking about 100% Free
Software here :-)

An event is currently characterized with the following properties:
- a unique ID
- a timestamp
- a script filename/line number
- an event level corresponding to error levels
- a message

A "slow request" is characterized with the following properties:
- a unique ID
- a timestamp
- a script filename
- a duration

We'd like to have your opinion on our "next steps", what is the most
important feature according to you:
- The development of the central aggregator
- Collecting more info related to an "event" (content of variables
$GLOBALS, $_GET, $_POST,...)
- alert systems (SNMP, Mailing, ...)
- Web services
- extending the webfrontend

Any similarity with existing Israeli products is purely coincidental. :-)

Thanks for your help,
Patrick

  



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] The constant use of isset()

[Olivier B.]

Sean Coates a écrit :

So if the variable is set and contains "false", we can't check it ?
And near same problem for 0, empty array and empty string.


How would you ever get false (the value, not the string) into a 
request variable? (without setting it that way after the request init, 
that is)
So this isset() behavior will only be available for request variable, 
not for all variables ?


I can't do that ? $a = isset($foo['bar'])


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] The constant use of isset()

[Olivier B.]

So if the variable is set and contains "false", we can't check it ?
And near same problem for 0, empty array and empty string.

But you can also use this syntax : (yes it's not very "clean")

   if( @$_GET['foo'] === 'bar')
   or
   if( @$_GET['foo'] === 'bar' or @$_GET['baz'] === 'bat' )


Olivier

Ólafur Waage a écrit :

While researching for this suggestion I found this rfc proposal regarding
ifsetor() ( 
http://wiki.php.net/rfc/ifsetor?s[]=isset)
and it's rejection point was that it was currently not possible (
http://marc.info/?l=php-internals&m=108931281901389&w=2 )

But would it be possible to check for a value of a variable if it is set?

Since I often do (and see others do)

if(isset($_GET["foo"]) && $_GET["foo"] == "bar")
or even worse
if((isset($_GET["foo"]) && $_GET["foo"] == "bar") || (isset($_GET["baz"]) &&
$_GET["baz"] == "bat"))

to be able to do something like this

if(isset($_GET["foo"]) == "bar")
or
if(isset($_GET["foo"]) == "bar" || isset($_GET["baz"]) == "bat")

That isset (or some other language construct) would return the variable if
it were set and false if it was not.

Thanks for your time, i know this has probably been talked to death in one
form or other.

Ólafur Waage
olaf...@gmail.com

  


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Are there plans to allow anonymous functions as callbacks?

[Olivier B.]

Alexey Zakhlestin a écrit :

On Wed, Mar 4, 2009 at 2:33 PM, Richard Quadling
 wrote:
  

Hi.

Quite a simple question (assuming I've got the terminology correct).

Are there any plans to allow code like this (amended example taken
from the array_map() documentation) ...




It works. You have a typo. You need to put ";" after return (…)

  

Hi,

with PHP < 5.3, you can also use create_function() 
(http://www.php.net/create_function )


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Vote: allow_call_time_pass_reference value in production INI

[Olivier B.]

Eric Stewart a écrit :

allow_call_time_pass_reference = Off (Issue Warnings)
  

Hello,

+1 too.

Olivier

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Invalid read at zend_objects_store_del_ref_by_handle #47353

[Olivier B.]

Hi,

this is a small script to reproduce that problem :


Note : that is dependent of the size of the array. With a value of 1000, 
I haven't got the error.


I verify that problem on PHP 5.2.6 (debian lenny), php5.2-200902060730 
and php5.3-200902101330.


And I report a bug : http://bugs.php.net/bug.php?id=47353

Thanks,
Olivier

Antony Dovgal a écrit :

On 07.02.2009 01:34, Olivier Bonvalet wrote:
  

And... if I'm not able to identify which part of the script do that ?



Remove parts of the code one by one, trying to see which parts affect it and 
which do not.
Finally you should get only those parts of the code, which are required to 
reproduce it.

  
I don't know valgrind, is it possible to obtain some informations about 
the partion of code which produce that ?



It does show the part of the code which produces it, but the problem is 
that it's part of C code, not PHP code and your issue happens on shutdown, 
which means something somewhere went wrong BEFORE that point.


  
I suppose the name of the C functions should help to identify that, no ? 
And zend_objects_store_del_ref is about object creation or destruction ? 



Object destruction, right.

  

And, it's an object created thought zim_PDOStatement_fetchObject ?



It seems so, yes. 
It makes sense to start looking into that direction if you want to create a reproduce script.


  



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Invalid read at zend_objects_store_del_ref_by_handle

[Olivier B.]

Hello,

I have an other memory corruption problem ; I had the problem on PHP 
5.2.6 on Debian Lenny (64bits), so I re-checked with the CVS version 
(php5.2-200902060730).


When I run my (really huge) cli-script with valgrind, I obtain this :

==22716== Invalid read of size 4
==22716==at 0x73EC38: zend_objects_store_del_ref_by_handle 
(zend_objects_API.c:203)
==22716==by 0x73EAA3: zend_objects_store_del_ref 
(zend_objects_API.c:168)

==22716==by 0x7148A1: _zval_dtor_func (zend_variables.c:52)
==22716==by 0x740190: _zval_dtor (zend_variables.h:35)
==22716==by 0x744E02: zend_assign_to_variable (zend_execute.c:804)
==22716==by 0x796752: ZEND_ASSIGN_SPEC_CV_VAR_HANDLER 
(zend_vm_execute.h:24593)

==22716==by 0x740F3A: execute (zend_vm_execute.h:92)
==22716==by 0x74169B: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:234)
==22716==by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(zend_vm_execute.h:322)

==22716==by 0x740F3A: execute (zend_vm_execute.h:92)
==22716==by 0x74169B: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:234)
==22716==by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(zend_vm_execute.h:322)
==22716==  Address 0x71f3ac0 is 9,064 bytes inside a block of size 
49,152 free'd

==22716==at 0x4C22741: realloc (vg_replace_malloc.c:429)
==22716==by 0x6F4BEB: _erealloc (zend_alloc.c:2314)
==22716==by 0x73E8CA: zend_objects_store_put (zend_objects_API.c:110)
==22716==by 0x73A654: zend_objects_new (zend_objects.c:132)
==22716==by 0x71B49D: _object_and_properties_init (zend_API.c:949)
==22716==by 0x71B5A8: _object_init_ex (zend_API.c:965)
==22716==by 0x4F72F1: do_fetch (pdo_stmt.c:1033)
==22716==by 0x4F8B9D: zim_PDOStatement_fetchObject (pdo_stmt.c:1454)
==22716==by 0x7414CA: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:200)
==22716==by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(zend_vm_execute.h:322)

==22716==by 0x740F3A: execute (zend_vm_execute.h:92)
==22716==by 0x74169B: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:234)

==22716==
==22716== Invalid read of size 4
==22716==at 0x73ED3B: zend_objects_store_del_ref_by_handle 
(zend_objects_API.c:216)
==22716==by 0x73EAA3: zend_objects_store_del_ref 
(zend_objects_API.c:168)

==22716==by 0x7148A1: _zval_dtor_func (zend_variables.c:52)
==22716==by 0x740190: _zval_dtor (zend_variables.h:35)
==22716==by 0x744E02: zend_assign_to_variable (zend_execute.c:804)
==22716==by 0x796752: ZEND_ASSIGN_SPEC_CV_VAR_HANDLER 
(zend_vm_execute.h:24593)

==22716==by 0x740F3A: execute (zend_vm_execute.h:92)
==22716==by 0x74169B: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:234)
==22716==by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(zend_vm_execute.h:322)

==22716==by 0x740F3A: execute (zend_vm_execute.h:92)
==22716==by 0x74169B: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:234)
==22716==by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(zend_vm_execute.h:322)
==22716==  Address 0x71f3ac0 is 9,064 bytes inside a block of size 
49,152 free'd

==22716==at 0x4C22741: realloc (vg_replace_malloc.c:429)
==22716==by 0x6F4BEB: _erealloc (zend_alloc.c:2314)
==22716==by 0x73E8CA: zend_objects_store_put (zend_objects_API.c:110)
==22716==by 0x73A654: zend_objects_new (zend_objects.c:132)
==22716==by 0x71B49D: _object_and_properties_init (zend_API.c:949)
==22716==by 0x71B5A8: _object_init_ex (zend_API.c:965)
==22716==by 0x4F72F1: do_fetch (pdo_stmt.c:1033)
==22716==by 0x4F8B9D: zim_PDOStatement_fetchObject (pdo_stmt.c:1454)
==22716==by 0x7414CA: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:200)
==22716==by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(zend_vm_execute.h:322)

==22716==by 0x740F3A: execute (zend_vm_execute.h:92)
==22716==by 0x74169B: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:234)

==22716==
==22716== Invalid write of size 4
==22716==at 0x73ED45: zend_objects_store_del_ref_by_handle 
(zend_objects_API.c:216)
==22716==by 0x73EAA3: zend_objects_store_del_ref 
(zend_objects_API.c:168)

==22716==by 0x7148A1: _zval_dtor_func (zend_variables.c:52)
==22716==by 0x740190: _zval_dtor (zend_variables.h:35)
==22716==by 0x744E02: zend_assign_to_variable (zend_execute.c:804)
==22716==by 0x796752: ZEND_ASSIGN_SPEC_CV_VAR_HANDLER 
(zend_vm_execute.h:24593)

==22716==by 0x740F3A: execute (zend_vm_execute.h:92)
==22716==by 0x74169B: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:234)
==22716==by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(zend_vm_execute.h:322)

==22716==by 0x740F3A: execute (zend_vm_execute.h:92)
==22716==by 0x74169B: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:234)
==22716==by 0x742357: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(zend_vm_execute.h:322)
==22716==  Address 0x71f3ac0 is 9,064 bytes inside a block of size 
49,152 free'd

==22716==at 0x4C22741