Re: Memory leak

From: Date: Fri, 23 Jul 2004 20:36:43 +0000
Subject: Re: Memory leak
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-11522@lists.php.net to get a copy of this message
:) Ilia, you heard the man. I don't think he leaves you much choice unless you want to risk him waiting for you in a dark alley with a surprise :) Andi At 01:09 PM 7/23/2004 -0700, Sterling Hughes wrote:
dooooooooooooooooooalllllllllocccccccccccccccccaaaaaaaaaaaaaaaaaaa, damnit On Fri, 23 Jul 2004 09:54:27 -0700, Andi Gutmans <andi@zend.com> wrote: At 12:51 PM 7/23/2004 -0400, Ilia Alshanetsky wrote:
On July 23, 2004 12:40 pm, you wrote:
At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote:
On July 23, 2004 11:42 am, Andi Gutmans wrote:
Why do we need one extra byte?
We do not.
Anyway, the question is if we should return to alloca() or not.
I am
slightly in favor but don't feel very strongly about it.
Perhaps we could try a combination of the two, to ensure that no
script is
terminated due to a PHP crash if allocating on the stack fails. By
default
we can use alloca() if that fails to allocate the memory, we
could use
emalloc() and set a flag free code indicating which free function
should
be used.
I'm hesitant to slow down the general case (even if it's just an
additional
if()) statement. I'd revert to alloca() and we can always add a --paranoid-stack-allocation directive to configure to use emalloc() :)
The problem is that that this causes certain large script to just crash, without any meaningful information. Is the cost of 2 if()s really that pefromance prohibitive?
No it's not. But 2 and 2 and 2 is :) I guess we can go with the if()'s for now.... Argh... Want to write a patch? Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- ..I....I..


« previous php.internals (#11522) next »