Rekursive Funktion mit unerklärbaren Abbruch

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Nee. PHP bricht eine Verarbeitung nicht mit einem Apache-Restart ab. Das ist ein Bug.

    Kommentar


    • #17
      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)
      der speicherverbrauch ist gering, kommt kaum an 8 mb dran.

      s. auch http://www.php-security.org/MOPB/MOPB-02-2007.html

      http://bugs.php.net/bug.php?id=37612&edit=2
      Zuletzt geändert von penizillin; 04.06.2007, 18:21.

      Kommentar


      • #18
        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.
        Toller guru. Dazu sollte man wissen dass es rekursive funktionen gibt
        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


        • #19
          Abgesehen davon, kann ich mir sogar vorstellen das php sowas macht
          und irgendwann sagt dass das stacklevel zu tief ist oder ähnliches.
          glaube ich zwar nicht unbedingt, doch habe ich gesehen, dass in manchen situationen genau diese fehlermeldung ausgegeben wird.

          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, 20:32.

          Kommentar

          Lädt...
          X