Solution pour "Erreur fatale: niveau maximal d'imbrication des fonctions de '100' atteint, abandon!" en PHP

J'ai créé une fonction qui trouve toutes les URL dans un fichier html et répète le même processus pour chaque contenu html lié aux URL découvertes. La fonction est récursive et peut durer indéfiniment. Cependant, j'ai mis une limite à la récursivité en définissant une variable globale qui provoque l'arrêt de la récursivité après 100 récursions.

Cependant, php renvoie cette erreur:

Erreur fatale: niveau maximal d'imbrication des fonctions de «100» atteint, abandon! dans D: \ wamp \ www \ crawler1 \ simplehtmldom_1_5 \ simple_html_dom.php à la ligne 1355

J'ai trouvé une solution ici: augmenter la limite d'appels de fonction d'imbrication mais cela ne fonctionne pas dans mon cas.

Je cite l'une des réponses du lien mentionné ci-dessus. Veuillez y réfléchir.

"Avez-vous installé Zend, IonCube ou xDebug? Si oui, c'est probablement de là que vous obtenez cette erreur.

Je suis tombé dessus il y a quelques années, et c'est finalement Zend qui a mis cette limite là-bas, pas PHP. Bien sûr, le supprimer vous permettra> de dépasser les 100 itérations, mais vous finirez par atteindre les limites de la mémoire. "

Existe-t-il un moyen d'augmenter le niveau d'imbrication maximal des fonctions en PHP

Augmentez la valeur de xdebug.max_nesting_levelvotrephp.ini

Une solution simple a résolu mon problème. Je viens de commenter cette ligne:

zend_extension = "d:/wamp/bin/php/php5.3.8/zend_ext/php_xdebug-2.1.2-5.3-vc9.dll

dans mon php.inidossier. Cette extension limitait la pile à 100donc je l'ai désactivée. La fonction récursive fonctionne maintenant comme prévu.

Plutôt que d'opter pour des appels de fonction récursifs, utilisez un modèle de file d'attente pour aplatir la structure.

$queue = array('http://example.com/first/url');
while (count($queue)) {
    $url = array_shift($queue);

    $queue = array_merge($queue, find_urls($url));
}

function find_urls($url)
{
    $urls = array();

    // Some logic filling the variable

    return $urls;
}

Il existe différentes manières de le gérer. Vous pouvez garder une trace de plus d'informations si vous avez besoin d'informations sur l'origine ou les chemins traversés. Il existe également des files d'attente distribuées qui peuvent fonctionner sur un modèle similaire.

Une autre solution consiste à ajouter xdebug.max_nesting_level = 200votre php.ini

Plutôt que de désactiver xdebug, vous pouvez définir la limite supérieure comme

xdebug.max_nesting_level = 500

Il est également possible de corriger cela directement en php, par exemple dans le fichier de configuration de votre projet.

ini_set('xdebug.max_nesting_level', 200);

Accédez à votre fichier de configuration php.ini et modifiez la ligne suivante:

xdebug.max_nesting_level=100

à quelque chose comme:

xdebug.max_nesting_level=200

sur Ubuntu en utilisant PHP 5.59:
allez à `:

/etc/php5/cli/conf.d

et trouvez votre xdebug.ini dans ce répertoire , dans mon cas, c'est 20-xdebug.ini

et ajoutez cette ligne `

xdebug.max_nesting_level = 200

ou ca

xdebug.max_nesting_level = -1

réglez-le sur -1 et vous n'aurez pas à vous soucier de changer la valeur du niveau d'imbrication.

»

probablement arrivé à cause de xdebug.

Essayez de commenter la ligne suivante dans votre "php.ini" et redémarrez votre serveur pour recharger PHP.

  ";xdebug.max_nesting_level"

Essayez de chercher dans /etc/php5/conf.d/ pour voir s'il existe un fichier appelé xdebug.ini

max_nesting_level est égal à 100 par défaut

S'il n'est pas défini dans ce fichier, ajoutez:

xdebug.max_nesting_level=300

à la fin de la liste pour qu'il ressemble à ceci

xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.profiler_enable=0
xdebug.profiler_enable_trigger=1
xdebug.profiler_output_dir=/home/drupalpro/websites/logs/profiler
xdebug.max_nesting_level=300

vous pouvez ensuite utiliser le test de @ Andrey avant et après avoir effectué cette modification pour voir si cela fonctionne.

php -r 'function foo() { static $x = 1; echo "foo ", $x++, "\n"; foo(); } foo();'

php.ini:

xdebug.max_nesting_level = -1

Je ne suis pas tout à fait sûr que la valeur débordera et atteindra -1, mais elle n'atteindra jamais -1, ou elle fixera le max_nesting_level assez haut.

Vous pouvez convertir votre code récursif en un code itératif, qui simule la récursivité. Cela signifie que vous devez pousser l'état actuel (url, document, position dans le document, etc.) dans un tableau, lorsque vous atteignez un lien, et le sortir du tableau, lorsque ce lien est terminé.

Vous pouvez essayer de réduire l'imbrication en implémentant des nœuds de calcul parallèles (comme dans le calcul en cluster) au lieu d'augmenter le nombre d'appels de fonction d'imbrication.

Par exemple: vous définissez un nombre limité d'emplacements (ex. 100) et surveillez le nombre de "travailleurs" affectés à chacun / certains d'entre eux. Si des emplacements deviennent libres, vous mettez les ouvriers en attente "en eux".

Vérifiez la récursivité depuis la ligne de commande:

php -r 'function foo() { static $x = 1; echo "foo ", $x++, "\n"; foo(); } foo();'

si résultat> 100 ALORS vérifier la limite de mémoire;

Si vous utilisez Laravel, faites

composer update

Cela devrait être du travail.

<?php
ini_set('xdebug.max_nesting_level', 9999);
... your code ...

PS Remplacez 9999 par le numéro de votre choix.

J'ai eu une erreur lors de l'installation de nombreux plugins, donc l'erreur 100 a montré, y compris l'emplacement du dernier plugin que j'ai installé C: \ wamp \ www \ mysite \ wp-content \ plugins \ "..." donc j'ai supprimé ce plugin dossier sur le lecteur C: alors tout était revenu à la normale.Je pense que je dois limiter la quantité de plug-in que j'installe ou que j'ai activé. bonne chance j'espère que cela aide

Dans votre cas, il est certain que l'instance du robot d'exploration a plus de limite Xdebug pour tracer les informations d'erreur et de débogage.

Mais, dans d'autres cas, des erreurs comme sur PHP ou des fichiers core comme les bibliothèques CodeIgniter créeront un tel cas et si vous augmentez même le paramètre de niveau x-debug, il ne disparaîtra pas.

Alors, regardez attentivement votre code :).

Voici le problème dans mon cas.

J'avais une classe de service qui est une bibliothèque dans CodeIgniter. Avoir une fonction à l'intérieur comme ça.

 class PaymentService {

    private $CI;

    public function __construct() {

        $this->CI =& get_instance();

   }

  public function process(){
   //lots of Ci referencing here...
   }

Mon contrôleur comme suit:

$this->load->library('PaymentService');
$this->process_(); // see I got this wrong instead  it shoud be like 

L'appel de fonction sur la dernière ligne était erroné à cause de la faute de frappe, au lieu de cela, il aurait dû être comme ci-dessous:

$this->Payment_service->process(); //the library class name

Ensuite, je continuais à recevoir le message d'erreur de dépassement. Mais j'ai désactivé XDebug mais pas aidé. De toute façon, veuillez vérifier le nom de votre classe ou votre code pour un appel de fonction correct.

J'ai eu ce problème avec WordPress sur cloud9. Il s'avère que c'était le plugin W3 Caching. J'ai désactivé le plugin et cela a bien fonctionné.

Une autre solution si vous exécutez un script php dans la CLI (cmd)

Le fichier php.ini à modifier est différent dans ce cas. Dans mon installation WAMP, le fichier php.ini qui est chargé en ligne de commande est:

\wamp\bin\php\php5.5.12\php.ini

au lieu de \ wamp \ bin \ apache \ apache2.4.9 \ bin \ php.ini qui se charge lorsque php est exécuté à partir du navigateur

Vous pouvez également modifier la fonction {debug} dans modifier.debug_print_var.php, afin de limiter sa récursivité dans les objets.

Vers la ligne 45, avant:

$results .= '<br>' . str_repeat('&nbsp;', $depth * 2)
  . '<b> -&gt;' . strtr($curr_key, $_replace) . '</b> = '
  . smarty_modifier_debug_print_var($curr_val, ++$depth, $length);

Après :

$max_depth = 10;
$results .= '<br>' . str_repeat('&nbsp;', $depth * 2)
  . '<b> -&gt;' . strtr($curr_key, $_replace) . '</b> = '
  . ($depth > $max_depth ? 'Max recursion depth:'.(++$depth) : smarty_modifier_debug_print_var($curr_val, ++$depth, $length));

De cette façon, Xdebug se comportera toujours normalement: limiter la profondeur de récursivité dans var_dump et ainsi de suite. Comme il s'agit d'un problème intelligent, pas un problème Xdebug!

J'ai eu le même problème et j'adore comme ceci:

Ouvrez le fichier MySQL my.ini

Dans la section [mysqld], ajoutez la ligne suivante: innodb_force_recovery = 1

Enregistrez le fichier et essayez de démarrer MySQL

Supprimez cette ligne que vous venez d'ajouter et enregistrez