Nee. PHP bricht eine Verarbeitung nicht mit einem Apache-Restart ab. Das ist ein Bug.
Rekursive Funktion mit unerklärbaren Abbruch
Einklappen
X
-
einverstanden, habe memcheck drüber laufen lassen, bei ca. 4400 ist bei mir auch sense:Code:==6952== Stack overflow in thread 1: can't grow stack to 0xBE318FFC ==6952== ==6952== Process terminating with default action of signal 11 (SIGSEGV) ==6952== Access not within mapped region at address 0xBE318FFC ==6952== at 0x83BA08F: _zend_mm_alloc_int (in /usr/local/bin/php) ==6952== Stack overflow in thread 1: can't grow stack to 0xBE318FDC ==6952== ==6952== Process terminating with default action of signal 11 (SIGSEGV) ==6952== Access not within mapped region at address 0xBE318FDC ==6952== at 0x401D200: _vgnU_freeres (vg_preloaded.c:56) ==6952== ==6952== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 87 from 1) ==6952== malloc/free: in use at exit: 8,820,909 bytes in 16,808 blocks. ==6952== malloc/free: 17,988 allocs, 1,180 frees, 9,170,809 bytes allocated. ==6952== For counts of detected errors, rerun with: -v ==6952== searching for pointers to 16,808 not-freed blocks. ==6952== checked 10,913,684 bytes. ==6952== ==6952== LEAK SUMMARY: ==6952== definitely lost: 0 bytes in 0 blocks. ==6952== possibly lost: 0 bytes in 0 blocks. ==6952== still reachable: 8,820,909 bytes in 16,808 blocks. ==6952== suppressed: 0 bytes in 0 blocks. ==6952== Reachable blocks (those to which a pointer was found) are not shown. ==6952== To see them, rerun with: --show-reachable=yes Segmentation fault (core dumped)
s. auch http://www.php-security.org/MOPB/MOPB-02-2007.html
http://bugs.php.net/bug.php?id=37612&edit=2Zuletzt geändert von penizillin; 04.06.2007, 19:21.
Kommentar
-
Original geschrieben von s.heinrich
Laut B. sollte man bei mehr als 500 rekursiven Aufrufen auf Iterationen umsteigen (also while, for-next, do-until, etc.), da diese bei solchen Mengen bis zu 800% schneller abgearbeitet werden, als rekursive Aufrufe einer Funktion.
deren process aber iterativ ist. Nämlich genau dann wenn es sich
um tail-calls handelt. Damit ist dann auch kein overhead weil nicht für
jede reksursionstiefe ein neuer stackframe anfällt.
Es ist also wichtig zu unterscheiden ob der prozess rekursiv oder iterativ ist.
Jede weitere argumentation erübrigt sich aufgrund der fehlenden grundlage.
Abgesehen davon, kann ich mir sogar vorstellen das php sowas macht
und irgendwann sagt dass das stacklevel zu tief ist oder ähnliches.
Oder eben den apache mit in die tiefe zieht
greets(((call/cc call/cc) (lambda (x) x)) "Scheme just rocks! and Ruby is magic!")
Kommentar
-
Abgesehen davon, kann ich mir sogar vorstellen das php sowas macht
und irgendwann sagt dass das stacklevel zu tief ist oder ähnliches.
http://www.alternateinterior.com/200...on-in-php.html
das ist aber ganz schön umständlich und es wohl kaum wert.Zuletzt geändert von penizillin; 05.06.2007, 21:32.
Kommentar
Kommentar