Everything

php

Segfault in HEAD

php.internals

Antony Dovgal

22 years ago

Hi all!

This small script:
<?

class test {
var $a = false;
var $x = false;

function getA() {
if (!$this->x) { // yep, I know, it's infinite loop
$this->foo();
}
return $this->a;
}

function foo() {
return $this->getA();
}
}

$test = new test;
$test->getA();

?>
produces segfault in latest HEAD.

A small part of backtrace(it's really huge) is below:

Program received signal SIGSEGV, Segmentation fault.
0x40325455 in zend_fetch_obj_r_handler (execute_data=0xbf8000e0, opline=0x40f3a96c, op_array=0x40f39b84) at /home/tony/CVS/php-src/Zend/zend_execute.c:2120
2120            zend_fetch_property_address_read(&opline->result, &opline->op1, &opline->op2, EX(Ts), BP_VAR_R TSRMLS_CC);
(gdb) bt
#0  0x40325455 in zend_fetch_obj_r_handler (execute_data=0xbf8000e0, opline=0x40f3a96c, op_array=0x40f39b84) at /home/tony/CVS/php-src/Zend/zend_execute.c:2120
#1  0x403237ba in execute (op_array=0x40f39b84) at /home/tony/CVS/php-src/Zend/zend_execute.c:1391
#2  0x40326f19 in zend_do_fcall_common_helper (execute_data=0xbf800210, opline=0x40f3acc0, op_array=0x40f39d6c) at /home/tony/CVS/php-src/Zend/zend_execute.c:2728
#3  0x40327223 in zend_do_fcall_by_name_handler (execute_data=0x40f39b84, opline=0x40f3a970, op_array=0x40f3a970) at /home/tony/CVS/php-src/Zend/zend_execute.c:2810
#4  0x403237ba in execute (op_array=0x40f39d6c) at /home/tony/CVS/php-src/Zend/zend_execute.c:1391
#5  0x40326f19 in zend_do_fcall_common_helper (execute_data=0xbf800390, opline=0x40f3aa9c, op_array=0x40f39b84) at /home/tony/CVS/php-src/Zend/zend_execute.c:2728
#6  0x40327223 in zend_do_fcall_by_name_handler (execute_data=0x40f39b84, opline=0x40f3a970, op_array=0x40f3a970) at /home/tony/CVS/php-src/Zend/zend_execute.c:2810
#7  0x403237ba in execute (op_array=0x40f39b84) at /home/tony/CVS/php-src/Zend/zend_execute.c:1391
#8  0x40326f19 in zend_do_fcall_common_helper (execute_data=0xbf8004c0, opline=0x40f3acc0, op_array=0x40f39d6c) at /home/tony/CVS/php-src/Zend/zend_execute.c:2728
#9  0x40327223 in zend_do_fcall_by_name_handler (execute_data=0x40f39b84, opline=0x40f3a970, op_array=0x40f3a970) at /home/tony/CVS/php-src/Zend/zend_execute.c:2810
#10 0x403237ba in execute (op_array=0x40f39d6c) at /home/tony/CVS/php-src/Zend/zend_execute.c:1391
#11 0x40326f19 in zend_do_fcall_common_helper (execute_data=0xbf800640, opline=0x40f3aa9c, op_array=0x40f39b84) at /home/tony/CVS/php-src/Zend/zend_execute.c:2728
#12 0x40327223 in zend_do_fcall_by_name_handler (execute_data=0x40f39b84, opline=0x40f3a970, op_array=0x40f3a970) at /home/tony/CVS/php-src/Zend/zend_execute.c:2810
#13 0x403237ba in execute (op_array=0x40f39b84) at /home/tony/CVS/php-src/Zend/zend_execute.c:1391
....

---
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net || antony@dovgal.com

Derick Rethans

22 years ago

On Wed, 31 Mar 2004, Antony Dovgal wrote:

> Hi all!
>
> This small script:
> <?
>
> class test {
> 	var $a = false;
> 	var $x = false;
>
> 	function getA() {
> 		if (!$this->x) { // yep, I know, it's infinite loop

PHP always crashes on infinite loops as you might be aware off. You'll
have to live with it.

regards,
Derick

Antony Dovgal

22 years ago

On Wed, 31 Mar 2004 09:27:42 +0200 (CEST)
Derick Rethans <derick@php.net> wrote:

> On Wed, 31 Mar 2004, Antony Dovgal wrote:
>
> > Hi all!
> >
> > This small script:
> > <?
> >
> > class test {
> > 	var $a = false;
> > 	var $x = false;
> >
> > 	function getA() {
> > 		if (!$this->x) { // yep, I know, it's infinite loop
>
> PHP always crashes on infinite loops as you might be aware off. You'll
> have to live with it.

And there is no workarounds at all?
(BTW, same results with PHP_4_3..)

---
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net || antony@dovgal.com

Derick Rethans

22 years ago

On Wed, 31 Mar 2004, Antony Dovgal wrote:

> > PHP always crashes on infinite loops as you might be aware off. You'll
> > have to live with it.
>
> And there is no workarounds at all?
> (BTW, same results with PHP_4_3..)

Just don't make infinite loops? :)

Derick

Sterling Hughes

22 years ago

php5 shouldn't crash _at all_ within an infinite loop because we aren't
in one big execution loop.

-sterling

On Mar 30, 2004, at 11:27 PM, Derick Rethans wrote:

George Schlossnagle

22 years ago

On Mar 31, 2004, at 1:17 PM, Sterling Hughes wrote:

> php5 shouldn't crash _at all_ within an infinite loop because we
> aren't in one big execution loop.

Why shouldn't this crash eventually?  You still have to account for all
the callers stacks.

George

Andi Gutmans

22 years ago

Sterling,

It's a stack overflow caused by an infinite loop in function calls (i.e.
not while/for loop).

Andi

At 10:17 AM 3/31/2004 -0800, Sterling Hughes wrote:

Antony Dovgal

22 years ago

On Thu, 01 Apr 2004 10:36:43 +0200
Andi Gutmans <andi@zend.com> wrote:

> Sterling,
>
> It's a stack overflow caused by an infinite loop in function calls (i.e.
> not while/for loop).

So, it's ok and won't be fixed ?

---
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net || antony@dovgal.com

Derick Rethans

22 years ago

On Thu, 1 Apr 2004, Antony Dovgal wrote:

> On Thu, 01 Apr 2004 10:36:43 +0200
> Andi Gutmans <andi@zend.com> wrote:
>
> > Sterling,
> >
> > It's a stack overflow caused by an infinite loop in function calls (i.e.
> > not while/for loop).
>
> So, it's ok and won't be fixed ?

Exactly (though adding in a hard limit IS possible quite easily).

Derick

Andi Gutmans

22 years ago

At 12:41 PM 4/1/2004 +0400, Antony Dovgal wrote:

>On Thu, 01 Apr 2004 10:36:43 +0200
>Andi Gutmans <andi@zend.com> wrote:
>
> > Sterling,
> >
> > It's a stack overflow caused by an infinite loop in function calls (i.e.
> > not while/for loop).
>
>So, it's ok and won't be fixed ?

This has been discussed many times. The only way to fix it in a platform
independent way is to add if() checks to see that we're not reaching some
arbitrary limit. This kind of sucks so we decided not to fix it.
On multi-process Apache this is a good decision because it's no biggy if
the server crashes. It might need to be fixed for MT-safe builds but
there's always the question of what the arbitrary limit should be. It
depends according to your script how much of the stack is being used. So
the limit we give by default might be too high or too low.

Andi