[PHP] Infinite recursion -> Webserver restarts: Acceptable?

[Olaf van der Spek]

In een script deed ik een Replace in Files om mysql_query te vervangen door een wrapper, alleen wist ik niet dat de wrapper al in de code stond en dus had ik een mooie vorm van infinite recursion.
Simpel voorbeeld:

PHP:

<?php
    function f()
    {
        f();
    }

    f();
?>

Ik run het script en zie geen output, dus ik de bug zoeken en na een uur gevonden.
Ik ben niet de enige:
http://bugs.php.net/bug.php?id=28139

De PHP crew bestempelt deze bug alleen als bogus. Is dit normaal?
Een scripting taal mag toch niet de hele webserver laten restarten?
Vooral zonder enige aanwijzing is het vinden van de stack overflow nogal lastig.

Omgeving:
Windows XP SP2
Apache/2.0.50 (Win32)
PHP/4.3.9

[ Voor 8% gewijzigd door Olaf van der Spek op 25-09-2004 19:08 ]

[Macros]

Infinite recursion zorgt of voor:
- oneindig veel data
- stack overflow
- niks

PHP heeft dus voor optie 3 gekozen. Voor grote projecten kan het lastig zijn, maar dat zal met php vaak niet het geval zijn. PHP probeert meestal de meest forgiving solution te kiezen. Waarschijnlijk dachten ze dat dat optie 3 is.
Ik vind het niet echt een probleem.

[Grijze Vos]

Bij een oneindig loopje moet er iets crashen he. Kennelijk kan apache niet alleen die ene thread laten crashen en restart je webserver. Wees blij dat ie zo zinnig is om opnieuw op te starten.

[Olaf van der Spek]

Macros schreef op 25 september 2004 @ 02:42:
Infinite recursion zorgt of voor:
- oneindig veel data
- stack overflow
- niks

PHP heeft dus voor optie 3 gekozen. Voor grote projecten kan het lastig zijn, maar dat zal met php vaak niet het geval zijn. PHP probeert meestal de meest forgiving solution te kiezen. Waarschijnlijk dachten ze dat dat optie 3 is.
Ik vind het niet echt een probleem.

Volgens mij heeft PHP voor 2 gekozen, aangezien de webserver restart.
Maar dit kan toch niet de bedoeling zijn van een scripting language?
Zeker bij shared servers is dit aardig vervelend voor de andere gebruikers.

Bij een oneindig loopje moet er iets crashen he.

Ja, het script mag crashen, maar PHP en Apache zelf niet.

[ Voor 8% gewijzigd door Olaf van der Spek op 25-09-2004 10:06 ]

[djc]

Volgens mij zou het script in de meeste gevallen ten onder moeten gaan aan of teveel geheugen-gebruik (kan je instellen in php.ini) of een te lange uitvoeringstijd (kan je ook instellen). Het zou de webserver dan niet moeten crashen. Maar dit hangt er natuurlijk wel een beetje hoe PHP geconfigureerd is, en hoe intensief de code in het recursieve block is.

Volgens mij heb ik mijn Apache nog nooit laten crashen naar door infinite recursion, maar dat zou kunnen komen omdat ik nooit recursie gebruik.

[Grijze Vos]

op de prompt bij een server (PHP5) krijg ik dit:

(greyfox@bierenfriet)~ $php test.php
Allowed memory size of 8388608 bytes exhausted (tried to allocate 256 bytes)

Als apache module:
geen output, dit staat in de logs:

Allowed memory size of 8388608 bytes exhausted (tried to allocate 256 bytes)
-----------

bij een andere (PHP4):

[Toad] </home/greyfox> php test.php
Segmentation fault

Als apache module:

Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 40 bytes) in /toad.mnt/alcoholism/html/greyfox/test.php on line 4


--------------
Voor zover ik kan zien geen apache crashes hoor..

[ Voor 7% gewijzigd door Grijze Vos op 25-09-2004 17:47 ]

[Verwijderd]

Ik kan me wel voorstellen dat het flink misgaat als er geen memory_limit is ingesteld.

[Grijze Vos]

Ik denk dat dat dan ook de reden is van de server crash waar de TS van spreekt.

[Olaf van der Spek]

Grijze Vos schreef op 25 september 2004 @ 17:47:
Voor zover ik kan zien geen apache crashes hoor..

Eh, Windows XP?
Het gaat vooral om de threaded MPM.
Onder Linux wordt vaak de prefork MPM gebruikt en als daar een process crashed, gaat niet de hele server onderuit.

[igmar]

OlafvdSpek schreef op 25 september 2004 @ 00:45:
De PHP crew bestempelt deze bug alleen als bogus. Is dit normaal?

Ja. Elke functie call in PHP is d'r ook een in de onderliggende PHP functies. Aangezien functie calls een waarde op de stack zetten, en die stack niet oneindig is geeft inifinite recursie dus getoonde problemen.

Een scripting taal mag toch niet de hele webserver laten restarten?

Sja. Geen threaded webservers draaien, dan heb je dit probleem niet.

Vooral zonder enige aanwijzing is het vinden van de stack overflow nogal lastig.

Da's iets wat OS afhankelijk is.

[djc]

OlafvdSpek schreef op 25 september 2004 @ 19:05:
Het gaat vooral om de threaded MPM.

Volgens mij wordt het gebruik daarvan sowieso afgeraden door de PHP crew omdat veel extensies niet threadsafe zijn.

[Grijze Vos]

OlafvdSpek schreef op 25 september 2004 @ 19:05:
[...]

Eh, Windows XP?

Hardstikke leuk als thuis OS, maar voor servers kies ik toch liever voor het stabiele FreeBSD.

[Olaf van der Spek]

igmar schreef op 26 september 2004 @ 14:48:
Ja. Elke functie call in PHP is d'r ook een in de onderliggende PHP functies. Aangezien functie calls een waarde op de stack zetten, en die stack niet oneindig is geeft inifinite recursie dus getoonde problemen.

Dat het een probleem geeft is natuurlijk normaal.
Maar jij dat interpreter crashed is toch niet normaal?

Als een normale app crashed, wil ik ook niet dat het onderliggende OS meegaat.
Van een script interpreter verwacht ik toch eigenlijk hetzelfde.

Da's iets wat OS afhankelijk is.

Is dat zo?
Ook onder Linux zie ik geen melding van een stack overflow.

[Olaf van der Spek]

Ik heb nu een andere bug gevonden met hetzelfde effect.
Een aanroep van gzinflate met invalid input resulteert in de volgende fatal error: FATAL: erealloc(): Unable to allocate 603602944 bytes

Deze bug wordt ook geclassificeerd als bogus, terwijl er met het script niks mis is.
De normale versie van gzip crashed ook niet op invalid input, maar PHP dus wel.

Grijze Vos schreef op 26 september 2004 @ 15:09:
Hardstikke leuk als thuis OS, maar voor servers kies ik toch liever voor het stabiele FreeBSD.

Ook onder FreeBSD is een threaded server sneller dan een 'processed' server, toch?