Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:2116 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17445 invoked from network); 1 Jun 2003 00:34:53 -0000 Received: from unknown (HELO mailout01.sul.t-online.com) (194.25.134.80) by pb1.pair.com with SMTP; 1 Jun 2003 00:34:53 -0000 Received: from fwd08.sul.t-online.de by mailout01.sul.t-online.com with smtp id 19MGoF-0004Fv-00; Sun, 01 Jun 2003 02:34:51 +0200 Received: from baumbart.post.rwth-aachen.de (520072483730-0001@[80.142.152.120]) by fwd08.sul.t-online.com with esmtp id 19MGo6-0ikZTUC; Sun, 1 Jun 2003 02:34:42 +0200 Reply-to:marcus.boerger@post.rwth-aachen.de Message-ID: <5.1.0.14.2.20030601023239.03084758@pop.t-online.de> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 01 Jun 2003 02:34:41 +0200 To: David Brown Cc: PHP Developers List In-Reply-To: <20030601000427.GA5775@codewhore.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Sender: 520072483730-0001@t-dialin.net Subject: Re: [PHP-DEV] Re: CVS commit in ZendEngine2/zend_execute.c From: marcus.boerger@t-online.de ((Marcus =?iso-8859-1?Q?B=F6rger?=)) References: <20030601000427.GA5775@codewhore.org> At 02:04 01.06.2003, David Brown wrote: > > zend_execute.c, 1.468 (sterling) > > Sat May 31 14:31:28 2003 (5 hours, 35 minutes ago) > > revert the function call caching patch until a new solution is decided > > upon. > >Hi: > >Is this being reverted due to a reported crash? If not, I'm currently >seeing several with the patch applied (which go away with the recent >revert). Valgrind says: > > Conditional jump or move depends on uninitialised value(s) > at 0x817367D: zend_init_fcall_by_name_handler (zend_execute.c:2565) > by 0x816EC54: execute (zend_execute.c:1247) > by 0x8173B14: zend_do_fcall_common_helper (zend_execute.c:2654) > by 0x8173F6A: zend_do_fcall_by_name_handler (zend_execute.c:2725) > >I can supply backtraces and try to derive a test case if this is a new >crash. If not, I'm relieved that I wasn't debugging alone - I've had a >'0 &&' in the reverted if() for the past 12 hours. :) Yes David, in ZTS mode it causes much problems, i found them some hours ago. But the main reason for revert is that the patch was done in the wrong way. Currently we are trying to figure out a new way since the performance boost is very good. regards marcus