[PHP-DEV] Bug #11009: Recursive call causes crash
From: [EMAIL PROTECTED]
Operating system: RedHat 6.2
PHP version: 4.0.5
PHP Bug Type: Reproducible crash
Bug description: Recursive call causes crash
I created a function called pad which performs exactly what str_repeat does (didn't
realize str_repeat was there originally).
function pad($length,$padVar=-){
if($length=0){return;}
else{return pad($length-1,$padVar).$padVar;}
}
When passing a length about 5000 the page will not load and I quickly get this error
in the php.error log:
[notice] child pid 15040 exit signal Segmentation fault (11)
I assume it is b/c the function stack is just not up to the task, but I thought I
would let you know anyway.
Of course I am using str_repeat now
Thanks!
Jason
--
Edit Bug report at: http://bugs.php.net/?id=11009edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11009 Updated: Recursive call causes crash
ID: 11009
User Update by: [EMAIL PROTECTED]
Status: Closed
Bug Type: Reproducible crash
Operating system: RedHat 6.2
PHP Version: 4.0.5
Description: Recursive call causes crash
Yeah, but the issue is not that I picked a bad way of doing this task, but whether
or not a recursive call should be able to go this deep in PHPi guess not.
Thanks for the help though,
Jas
Previous Comments:
---
[2001-05-22 00:06:08] [EMAIL PROTECTED]
I personally used sprintf for this job before str_repeat came along. However, it is a
useless argument now.
---
[2001-05-21 22:58:04] [EMAIL PROTECTED]
yeah, but a while($length--) was super slow (10-20 times slower)...actually timed-out
on the simplest runs.
maybe a for() is faster?!
---
[2001-05-21 22:53:16] [EMAIL PROTECTED]
This is more of a programing error. This is a poor way to use recursive calls. A
loop is the correct way to handle this.
---
[2001-05-21 22:06:27] [EMAIL PROTECTED]
I created a function called pad which performs exactly what str_repeat does (didn't
realize str_repeat was there originally).
function pad($length,$padVar=-){
if($length=0){return;}
else{return pad($length-1,$padVar).$padVar;}
}
When passing a length about 5000 the page will not load and I quickly get this error
in the php.error log:
[notice] child pid 15040 exit signal Segmentation fault (11)
I assume it is b/c the function stack is just not up to the task, but I thought I
would let you know anyway.
Of course I am using str_repeat now
Thanks!
Jason
---
Full Bug description available at: http://bugs.php.net/?id=11009
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10675: Executing background job from PHP causes session lock-up
From: [EMAIL PROTECTED] Operating system: RedHat 6.2 PHP version: 4.0.5 PHP Bug Type: *Session related Bug description: Executing background job from PHP causes session lock-up Executed a perl script in the background like this: perl scriptname.pl $otherParams 2 /dev/null 1 /dev/null Perl script forks and parent dies, so PHP should see the script as finished immediately, perl child does work in background (takes a few minutes to run). PHP script that spawned perl script completes OK, browser stops waiting for more data from php script as it should. However, when using the same browser window (or one from browser's file-new window) no other pages that referrence the session will load in the browser. If we force the session to destroy just after the system() call, other scripts load just fine. Also, other scripts work just fine if we start a new browser from scratch (creates new session). So it appears that the PHP session is getting messed up somehow b/c of the background system/exec/`` call. This seems to prevent the following pages from loading the session properly and therefore they will not run. -- Edit Bug report at: http://bugs.php.net/?id=10675edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10675 Updated: Executing background job from PHP causes session lock-up
ID: 10675 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: *Session related Description: Executing background job from PHP causes session lock-up Executed a perl script in the background like this: perl scriptname.pl $otherParams 2 /dev/null 1 /dev/null Perl script forks and parent dies, so PHP should see the script as finished immediately, perl child does work in background (takes a few minutes to run). PHP script that spawned perl script completes OK, browser stops waiting for more data from php script as it should. However, when using the same browser window (or one from browser's file-new window) no other pages that referrence the session will load in the browser. If we force the session to destroy just after the system() call, other scripts load just fine. Also, other scripts work just fine if we start a new browser from scratch (creates new session). So it appears that the PHP session is getting messed up somehow b/c of the background system/exec/`` call. This seems to prevent the following pages from loading the session properly and therefore they will not run. One other thing, once the child perl script is finally complete everything starts working again, i.e.-the session is OK again. Previous Comments: --- [2001-05-04 15:22:47] [EMAIL PROTECTED] Executed a perl script in the background like this: perl scriptname.pl $otherParams 2 /dev/null 1 /dev/null Perl script forks and parent dies, so PHP should see the script as finished immediately, perl child does work in background (takes a few minutes to run). PHP script that spawned perl script completes OK, browser stops waiting for more data from php script as it should. However, when using the same browser window (or one from browser's file-new window) no other pages that referrence the session will load in the browser. If we force the session to destroy just after the system() call, other scripts load just fine. Also, other scripts work just fine if we start a new browser from scratch (creates new session). So it appears that the PHP session is getting messed up somehow b/c of the background system/exec/`` call. This seems to prevent the following pages from loading the session properly and therefore they will not run. --- Full Bug description available at: http://bugs.php.net/?id=10675 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
