Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:55694 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 5503 invoked from network); 3 Oct 2011 19:53:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Oct 2011 19:53:08 -0000 Authentication-Results: pb1.pair.com smtp.mail=tony@daylessday.org; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tony@daylessday.org; sender-id=pass Received-SPF: pass (pb1.pair.com: domain daylessday.org designates 95.163.84.66 as permitted sender) X-PHP-List-Original-Sender: tony@daylessday.org X-Host-Fingerprint: 95.163.84.66 mail.daylessday.org Received: from [95.163.84.66] ([95.163.84.66:53840] helo=daylessday.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 76/55-63914-2A21A8E4 for ; Mon, 03 Oct 2011 15:53:07 -0400 Received: from thinkx201.site (unknown [176.14.151.183]) by daylessday.org (Postfix) with ESMTPSA id 95349E35EB for ; Mon, 3 Oct 2011 23:53:10 +0400 (MSD) Message-ID: <4E8A129F.7090400@daylessday.org> Date: Mon, 03 Oct 2011 23:53:03 +0400 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110907 SUSE/3.1.14 Thunderbird/3.1.14 MIME-Version: 1.0 To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] zend memory managment null pointer dereference From: tony@daylessday.org (Antony Dovgal) 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