RE: [PHP-DEV] zend memory managment null pointer dereference
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
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
Re: [PHP-DEV] zend memory managment null pointer dereference
On 10/03/2011 11:42 PM, Chester, Alan wrote: Hi, I have recently seen httpd core dump on my system. After looking into this issue it is the php module which is actually core dumping more specifically the zend memory management part of php. #0 0x0115d224 in zend_mm_remove_from_free_list (heap=0x99596e8, p=) at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_alloc.c:837 This is the worst kind of segfault since GDB backtrace doesn't carry any useful information in this case, it just tells us that the crash has happened at the request shutdown. But the real problem that caused the crash has occurred somewhere during the request and there's no way to know when & where basing on the backtrace only. I'd suggest to try reproducing this problem with Valgrind: https://bugs.php.net/bugs-getting-valgrind-log.php, this would give us a lot more info. -- 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
