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 functi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
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 t
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
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
Hi all,
I've just been implementing a memcache session handler that allows for
multiple servers in a cluster to store their session data in a central
place. I had to make the changes in the PHP source as the user session
handler doesn't quite work properly (it wipes the references to the PHP
funct
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
One more RC, of PHP 5.2.0 is out, hopefully it'll be the last, but
past experience is not proving to be promising.
The RC can be downloaded from here: http://downloads.php.net/ilia/
php-5.2.0RC6.tar.bz2 (md5: 5a146c08f85d8535c76fe6219281a06e).
Hello,
On 10/20/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
I proposed PEAR package, and accepted by PEPr.
The following links are the packages accepted:
http://pear.php.net/pepr/pepr-proposal-show.php?id=441
And, I send "CVS Account Request: kouichi66" at 2006/10/12.
But, I cannot login t
I'm experiencing a strange random crash in PHP 5.1.4 and 5.1.6
triggered by several separate sections of code under a number of
circumstances. I can't narrow it down much, but the backtrace always
ends with:
(gdb) bt
#0 0x081f80fe in _erealloc (ptr=0x8531b44, size=2, allow_failure=0)
at
I proposed PEAR package, and accepted by PEPr.
The following links are the packages accepted:
http://pear.php.net/pepr/pepr-proposal-show.php?id=441
And, I send "CVS Account Request: kouichi66" at 2006/10/12.
But, I cannot login to CVS Server.
I want to know why cannot login.
- I yet do not get
On Thu, 19 Oct 2006 23:26:42 +0200
[EMAIL PROTECTED] (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.
>
>
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.
I am talking about this change:
http://marc.theaimsgroup.com/?l=php-dev&m=114734977430980&
Brian Moon wrote:
Evert | Rooftop wrote:
Thats a smart idea.. I like that
As for letting PHP do the 500, I tend to use output buffering
everywhere (i think most people do, supposed to be faster too) so I'm
used to setting header()'s wherever I need them..
You think wrong. There are very go
Evert | Rooftop wrote:
Thats a smart idea.. I like that
As for letting PHP do the 500, I tend to use output buffering everywhere
(i think most people do, supposed to be faster too) so I'm used to
setting header()'s wherever I need them..
You think wrong. There are very good reasons not to u
Thats a smart idea.. I like that
As for letting PHP do the 500, I tend to use output buffering everywhere
(i think most people do, supposed to be faster too) so I'm used to
setting header()'s wherever I need them..
Besides, in most of my script the business logic gets executed first,
and thi
Evert | Rooftop wrote:
Excuse me if this has been discussed before, but I would like to know
the stance on this issue, it's hard to search the buglist or mailing
archives on stuff like http, 500 and fatal.
Would it be hard to implement an ini setting for throwing a http 500
error on a fatal e
Excuse me if this has been discussed before, but I would like to know
the stance on this issue, it's hard to search the buglist or mailing
archives on stuff like http, 500 and fatal.
Would it be hard to implement an ini setting for throwing a http 500
error on a fatal error? It's hard to make
16 matches
Mail list logo
