Re: Memory leak

Sterling's not as tough as he looks. On Jul 23, 2004, at 5:05 PM, Ilia Alshanetsky wrote:

Fine fine... let's rever it... I don't feel like carrying brass knuckles with me all the time. Ilia On July 23, 2004 04:36 pm, Andi Gutmans wrote:

:) 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..

-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php