# Acceptable Seg Faults?

- Thread: https://externals.io/message/25636
- Original archive: https://news-web.php.net/php.internals/25636
- Started by Ralph Schindler on 2006-09-12T18:42:37+00:00
- Messages: 4
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #25636 — Ralph Schindler — 2006-09-12T18:42:37+00:00

URL: https://externals.io/message/25636#25636

The following script produces a seg fault:

<?

$class = new MyClass();

class MyClass
{

     public function __construct()
     {
         $this->_start();
     }


     public function _start()
     {

         $this->_myCall();

     }

     public function _myCall()
     {
         $this->_start();
     }

}



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.

PHP 5.1.6 / Linux 2.6 / Apache 2
[notice] child pid 6688 exit signal Segmentation fault (11)


-Ralph

---

## #25637 — Johannes Schlueter — 2006-09-12T18:44:06+00:00

URL: https://externals.io/message/25636#25637 · In reply to: #25636

Yes, this is expected.

Ralph Schindler wrote:
> The following script produces a seg fault:
>
> <?
>
> $class = new MyClass();
>
> class MyClass
> {
>
>     public function __construct()
>     {
>         $this->_start();
>     }
>
>
>     public function _start()
>     {
>
>         $this->_myCall();
>
>     }
>
>     public function _myCall()
>     {
>         $this->_start();
>     }
>
> }
>
>
>
> 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.
>
> PHP 5.1.6 / Linux 2.6 / Apache 2
> [notice] child pid 6688 exit signal Segmentation fault (11)
>
>
> -Ralph

---

## #25638 — Stanislav Malyshev — 2006-09-12T19:00:57+00:00

URL: https://externals.io/message/25636#25638 · In reply to: #25636

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

-- 
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/

---

## #25646 — Unknown W. Brackets — 2006-09-13T03:01:31+00:00

URL: https://externals.io/message/25636#25646 · In reply to: #25638

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 --------

> > […]
> 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.