RE: [PHP-DEV] zend memory managment null pointer dereference

2011-10-04 Thread Chester, Alan 
Antony,

I am fairly confident we are not using any third party caching (ie apc, 
eAccelerator,etc).  However other then running php --version is there any other 
way to verify what caching system is being used?

[root@cab4en2b7 ~]# php --version
PHP 5.2.17 (cli) (built: Aug  2 2011 13:33:29)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans


Also trying to find a reproducer I have wrote a test php script which creates 
multiple objects and another script which sends signals to the script which is 
creating objects to try to get into the faulty cleanup.  I have had little 
success with this and was wondering if this is not the best way to try to 
reproduce this or if there is a better way which may cause the memory to get 
corrupted?  Also will this type of issue be seen with stand alone php or would 
I need this to be running with http?

Thanks,
Alan

 
-Original Message-
From: Antony Dovgal [mailto:t...@daylessday.org] 
Sent: Monday, October 03, 2011 4:21 PM
To: Chester, Alan; php-dev
Subject: Re: [PHP-DEV] zend memory managment null pointer dereference

On 10/04/2011 12:06 AM, Chester, Alan wrote:
 Antony,

 Thank you for the quick response.  I will work towards finding a reproducer 
 and using valgrind to gather more information.

 Since I have been trying for to find a reproducer but have had no luck so 
 far, do you think reducing the cache size
  would help in finding a reproducer? If so how is this done?  Or does 
 cache/cache size have nothing to do with this area of code?

Reducing the cache size will not help for sure, but disabling the cache 
entirely will
help us to understand whether this problem is caused by your cache or not.

Btw, you didn't specify which kind of cache is that.
  
 Also would you like to me open a bug ticket to track this issue?

It depends on the kind of cache you're using (there are several caches on the 
market
that aren't part of PHP project) and whether the cache is guilty or not.

-- 
Wbr,
Antony Dovgal
---
http://pinba.org - realtime profiling for PHP


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

[PHP-DEV] RM decision on BUG #55801 / FR #36424

2011-10-04 Thread Michael Wallner 
Hi, could the release manager(s) please take a 
decision on mentioned bug/feature request?

Thanks a lot,
Mike

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

[PHP-DEV] Re: Bug with static property access

2011-10-04 Thread Matthew Weier O'Phinney 
On 2011-10-03, Chris Stockton chrisstockto...@gmail.com wrote:
 Hello,

 I noticed the following odd behavior earlier today, there is
 definitely a bug here in my opinion, the bug is either the error
 message or the behavior. I think the behavior is possibly expected.
 I'll let some others comment.

 The reason I think the error is odd is because it is very misleading
 in a much larger code base (what I was debugging) you go to the line
 it is complaining about and are perplexed because you are not
 attempting to access the mentioned constant. I'm sure the engine does
 some kind of lazy/runtime determination that causes this, that area
 may need a look at?

 Example:
?php
 abstract class ClassA {
   static protected $_cache = Array();

   public $version = self::VERSION;

   final static public function MethodOne() {
 return __METHOD__;
   }

   final static public function MethodTwo() {
 self::$_cache;
 return __METHOD__;
   }
 }

 abstract class ClassB extends ClassA {
   const VERSION = 1;
 }

 var_dump(ClassB::MethodOne());
 var_dump(ClassB::MethodTwo());

 ?

 // prints
 string(17) ClassA::MethodOne
 Fatal error: Undefined class constant 'self::VERSION' in
SNIP/testbug.php on line 14

That makes complete sense to me -- ClassA is referring to self, which
resolves to ClassA... which does not define a VERSION constant. Change
to this:

public $version = static::VERSION;

and it should be fine.

-- 
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework  | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

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

Re: [PHP-DEV] Re: Bug with static property access

2011-10-04 Thread Chris Stockton 
Hello,

On Tue, Oct 4, 2011 at 11:33 AM, Matthew Weier O'Phinney
weierophin...@php.net wrote:

 That makes complete sense to me -- ClassA is referring to self, which
 resolves to ClassA... which does not define a VERSION constant. Change
 to this:

    public $version = static::VERSION;

 and it should be fine.


Hi Matt, I knew what was wrong with the code as soon as I saw it :- ),
the code itself was part of a much more complicated system and I was
using it in a unexpected way. The reason it was difficult to
troubleshoot is because the constant being whined about was not any
(of the several) constants being evaluated at the line the error was
for. I think the error should be thrown at compile time, not at
runtime ONLY when a constant is being accessed. This could cause
dangerous hard to catch errors that make it into production.

In addition, as I understand and would like to make you aware that
static is not allowed in compile time class constants. Which is
slightly unusual and perhaps could be changed because it seems that
there is already runtime resolving taking place here.

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