Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26107
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ilisys.com.au from 203.202.10.83 cause and error)
Message-ID: <45386C03.2060708@ilisys.com.au>
Date: Fri, 20 Oct 2006 14:26:11 +0800
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Christian Stocker <christian.stocker@bitflux.ch>
CC: Lukas Kahwe Smith <lsmith@php.net>,  internals@lists.php.net
References: <18.FF.27040.69DE7354@pb1.pair.com> <453857D8.3020704@bitflux.ch> <45385952.7040400@ilisys.com.au> <45386AB4.60504@albumltd.co.nz>
In-Reply-To: <45386AB4.60504@albumltd.co.nz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] a last plead
From: glenn.richmond@ilisys.com.au (Glenn Richmond)

ok, sure. I'll be working to get more information on this one. I should
have said that the line of code where it crashes is called constantly.
It's part of a parent class and is almost the most called code in the
system. It's only when it's called via the SOAP interface for a
particular SOAP function that the error occurs.

I've been tracking down information on the issue just within PHP with
echo messages etc. However, what is the best method for getting detailed
info on the bug? Are there ways to get memory usage, stack trace etc? I
don't mind getting into the c code if required.

Glenn.

Jasper Bryant-Greene wrote:
> Glenn,
>
> 'return $this' is perfectly acceptable and indeed very common code. It
> works fine for me in 5.1.4 - you might like to report a bug if you can
> reproduce a segfault...
>
> What is being referred to here is things like 'abstract static'
> functions that are completely meaningless from a theoretical point of
> view (static functions are bound to the class they are defined on and do
> not have inheritance rules so how can they be abstract?) but are still
> being used by some people.
>
> The argument is that we should not unnecessarily break these people's
> code just because it makes no sense. Personally, I don't buy into this
> argument. Perhaps if their code breaks and there is a good explanation
> in the error message, they might start writing OO code that isn't
> nonsensical.
>
> Jasper
>
>
> Glenn Richmond wrote:
> >> Hmm, this is interesting - I just joined the mailing list, but I can
> >> relate to this. I've come across a piece of code in that has the
> >> following line in a function within a class:
> >>
> >> return $this;
> >>
> >> It seems to cause an over-allocation of memory and ultimately a seg
> >> fault in both 5.1.4 and 5.2rc4, but works in 5.04. Is this the sort of
> >> this that you're referring to?
> >>
> >> Glenn.
> >>
> >> Christian Stocker wrote:
> >>> On 19.10.2006 23:26 Uhr, Lukas Kahwe Smith wrote:
> >>>   
> >>>> Hi,
> >>>>
> >>>> I just want to say once again that all hell is going to break
> loose once
> >>>> we release 5.2.0 as stable thanks to the various fatal errors we are
> >>>> adding for perfectly working code that breaks OO theory.
> >>>>
> >>>> Now is the time to fix this before RC6.
> >>>>     
> >>> +1 too here.
> >>>
> >>> It will IMHO slow down the adoption of 5.2, as - I assume - a
> >>> significant part of scripts will fatal out in 5.2. And this certainly
> >>> won't make all those people happy, who already had to rewrite their
> >>> programs for making them 5.0/1 compatible
> >>>
> >>> chregu
> >>>   
>
> --
> Jasper Bryant-Greene
> Director
> Album Limited
>
> jasper@albumltd.co.nz
> +64 21 708 334 / 0800 425 286
> http://www.albumltd.co.nz/