Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53309
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nouvo.com from 213.186.62.62 cause and error)
Message-ID: <4DF9A4E7.5090605@nouvo.com>
Date: Thu, 16 Jun 2011 08:38:31 +0200
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: PHP Developers Mailing List <internals@lists.php.net>
References: <alpine.DEB.2.02.1106071203020.5202@whisky> <8757232E56758B42B2EE4F9D2CA019C9014CE547@US-EX2.zend.net> <BANLkTinLd8svjZYGYOoc=qyxViFfapn=nA@mail.gmail.com> <8757232E56758B42B2EE4F9D2CA019C9014D10DC@US-EX2.zend.net> <BANLkTikj7NG6uig5mSB78Xs9m-8vU0dZuA@mail.gmail.com> <4DF9913B.4030404@nouvo.com> <4DF99368.2040508@sugarcrm.com> <4DF99949.1070601@nouvo.com> <4DF99E50.8040704@sugarcrm.com>
In-Reply-To: <4DF99E50.8040704@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)
From: Pascal.Courtois@nouvo.com (Pascal COURTOIS)

Le 16/06/2011 08:10, Stas Malyshev a écrit :
> Hi!
> 
>> what I did every single time. Among all my bug reports I had one
>> answer from decoder-php@own-hero.net (thanks to him) who reduced
>> the test case for a memory leak (bug 54460). I'm not talking about
>> bugs in modules but bugs in *core* which can be reproduced with few
>> lines of *core* PHP.
> 
> I am reading the list pretty closely and I don't remember any emails
> from you raising the question of reproducible corruption bugs
> recently, except indeed for 54460 which seems to be a memory leak,
> though presence of xcache in the trace suggests it may not even be a
> PHP bug. It talks about bug in a template engine containing thousands
> of lines. This is pretty hard work to debug something starting with
> huge unknown code, so no wonder nobody got to it yet. PHP is a
> volunteer project, and it's not easy to find volunteers to dig into
> thousand lines of unknown code to find a bug that may not even be
> there. It's quite a hard work.

  as I said earlier, test case was reduced to:

<?php
class TempleetRedirect extends Exception {};
Function parseform($template) {
        $txt = eval_list($templatecache[$template]['template']);
}
Function eval_list($array) {
            throw new TempleetRedirect($file);
}
Function parsetemplate($template) {
    $txt = parseform($template);
}
try 
  {  
    $output=parsetemplate($global_var['template']);
  }  
catch (TempleetRedirect $r)
  {
    exit();
  }
?>

 as you can see there's nothing but PHP core instructions in that code.


> I must have missed other ones. But if they are still reproducible in
> 5.4 and you have reproducing code, you're welcome to share on the
> list. Unfortunately, bugs.php.net seems to be down, but once it gets
> up we could look into it and see if we can fix any.

  for memory leaks if the bug is fixed it will not happen again but 
for memory corruption it's something totaly different. The fact that
a bug disapears doesn't mean in any way it has been fixed. 

> As I said, good
> reproduction makes it better.

  I've been debugging in lots of languages including assembly codes 
for over 30 years so I know precisely what you mean. So when it's
possible to reproduce a bug in some known conditions, the wait-and-see
attitude is not a good option because it's very likely that the bug
will disapear. Memory coruptions are much like terrorist attacks: 
you never know where and when it will happen.

  In bug 614904 I submitted a TWO lines program which crashed PHP on
a absolutely standard i386 debian install. I got no answer.
Of course the bug disapeared in following versions of PHP but what is fixed ?
Not as far as I know.