Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25646
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <95.A3.02095.98477054@pb1.pair.com>
To: internals@lists.php.net
Date: Tue, 12 Sep 2006 20:01:31 -0700
User-Agent: Thunderbird 1.5 (Windows/20051229)
MIME-Version: 1.0
References: <4506FF9D.4030903@smashlabs.com> <450703E9.3040106@zend.com>
In-Reply-To: <450703E9.3040106@zend.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Acceptable Seg Faults?
From: unknown@simplemachines.org ("Unknown W. Brackets")

Is it at all possible to determine in a cross-platform way:

1. The current stack position (e.g. SP, except on all architectures.)
2. The maximum stack size.

I realize this is a naive question, but given the above - worst-case, an 
option (like memory_limit) could be added which tracks recursion depth 
or stack usage and triggers an error within an acceptable limit.

Example: if you know each recursive PHP function call uses approximately 
X bytes of stack with its local variable table etc., and you know you 
have 2 megabytes of stack in your thread/process, you know you can only 
use a recursion depth of 2097152 / X, and you also know you won't have 
all of that.

Thus you could prevent segfaults even on shared servers.  Still, the 
solution is to have correct code.  The above would either have false 
negatives and/or introduce a performance loss (check or at least inc per 
user-space function call) when compiled on.

-[Unknown]

-------- Original Message --------

>> I assume this is b/c its recursively diving into Class function/method
>> calls and we are filling memory.. Is this detectable?  Should I file a
>> bug report or is this known?  Ideally it would be nice to see a fatal
>> error thrown, if this is indeed detectable.
> So far nobody had proposed a solution for endless loop problem that
> would satisfy these conditions:
> 1. No false positives (i.e. good code always works)
> 2. No slowdown for execution
> 3. Works with any stack size
> Thus, this problem remains unsloved.
>