La gestion de la mémoire n'a rien à se reprocher à mon avis. Et il n'y a pas de fuite de mémoire notable.
PHP utilise un allocateur spécial qui est réinitialisé après chaque requête (un peu comme Apache utilise un pool mémoire pour chaque requête). Donc même en cas de fuite mémoire, la mémoire serait récupérée à la fin de la requête.
php est capable de s'écraser lui même en parti, php n'est pas réentrant ...
Tu peux détailler ?
Le cas typique est une fonction qui boucle à l'infinie avec un final une page en module apache, pas de page en fastcgi.
Je pense que tu parle de récusion. En effet, PHP crash en cas de récursion trop profonde, parce que chaque niveau de récursion prend un peu de place sur la pile, et quand la pile est pleine, ça crash.
C'est pas spécique à PHP, si tu fais une "récursion infinie" en C tu obtiens exactement le même résultat.
D'ailleurs la seule façon d'obtenir un dépassement de pile depuis PHP 5.3 est de faire une récursion de fonctions natives, les fonctions utilisateur étant exécutées sans récursion, en interne.
une page en module apache, pas de page en fastcgi
Le fait est que dans un module apache, php est appelé par apache et donc la stack est déjà un peu remplie. Donc ça crash peut être une dizaine de récursions plus tôt, mais le comportement est le même en fastcgi.
La contrainte est qu'il faut assurer le recyclage des process, ce qui avec du code mal branlé et en haute charge peut se finir par un système qui passe son temps à forker. C'est aussi l'impossibilité d'utiliser php directement en threads ou en event.
De quoi tu parles ?
l'approche par sandboxing dans le core mais oui mais non (j'ai nommé le safe_mode, l'open_basedir
Ce sont des "features" dépréciée et désactivée par défaut dans 5.3.
Les fonctions magiques register_globals, magic_quotes
[^] # Re: Pour compléter...
Posté par __o . En réponse à la dépêche État d'insécurité chez PHP. Évalué à 6.
La gestion de la mémoire n'a rien à se reprocher à mon avis. Et il n'y a pas de fuite de mémoire notable.
PHP utilise un allocateur spécial qui est réinitialisé après chaque requête (un peu comme Apache utilise un pool mémoire pour chaque requête). Donc même en cas de fuite mémoire, la mémoire serait récupérée à la fin de la requête.
Tu peux détailler ?
Je pense que tu parle de récusion. En effet, PHP crash en cas de récursion trop profonde, parce que chaque niveau de récursion prend un peu de place sur la pile, et quand la pile est pleine, ça crash.
C'est pas spécique à PHP, si tu fais une "récursion infinie" en C tu obtiens exactement le même résultat.
D'ailleurs la seule façon d'obtenir un dépassement de pile depuis PHP 5.3 est de faire une récursion de fonctions natives, les fonctions utilisateur étant exécutées sans récursion, en interne.
Le fait est que dans un module apache, php est appelé par apache et donc la stack est déjà un peu remplie. Donc ça crash peut être une dizaine de récursions plus tôt, mais le comportement est le même en fastcgi.
De quoi tu parles ?
Ce sont des "features" dépréciée et désactivée par défaut dans 5.3.
même chose