「致命的エラー：関数のネストの最大レベル「100」に達したため、中止します！」の解決策 PHPで

htmlファイル内のすべてのURLを検索し、検出されたURLにリンクされている各h​​tmlコンテンツに対して同じプロセスを繰り返す関数を作成しました。関数は再帰的で、無限に続行できます。ただし、100回の再帰後に再帰を停止させるグローバル変数を設定することで、再帰に制限を設けています。

ただし、phpは次のエラーを返します。

致命的なエラー：関数のネストレベルが最大 '100'に達したため、中止します！D：\ wamp \ www \ crawler1 \ simplehtmldom_1_5 \ simple_html_dom.phpの1355行目

私はここで解決策を見つけました：ネスト関数呼び出しの制限を増やしていますが、これは私の場合は機能しません。

上記のリンクからの回答の1つを引用しています。どうぞご検討ください。

「Zend、IonCube、またはxDebugがインストールされていますか？インストールされている場合、それはおそらくこのエラーの原因です。

私は数年前にこの問題に遭遇しましたが、PHPではなくZendがその制限をそこに置いていました。もちろん、それを削除すると、100回の繰り返しを超えてしまいますが、最終的にはメモリ制限に達します。 "

PHPで関数のネストの最大レベルを上げる方法はありますか

値が増加xdebug.max_nesting_level中のあなたphp.ini

簡単な解決策が私の問題を解決しました。私はこの行にコメントしました：

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

私のphp.iniファイルで。この拡張機能はスタックを制限していた100ため、無効にしました。再帰関数は期待どおりに機能しています。

再帰的な関数呼び出しを行うのではなく、キューモデルを使用して構造をフラット化します。

$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;
}

それを処理するにはさまざまな方法があります。起点または通過したパスに関する洞察が必要な場合は、さらに多くの情報を追跡できます。同様のモデルで機能する分散キューもあります。

別の解決策はxdebug.max_nesting_level = 200、php.ini に追加することです

xdebugを無効にするのではなく、次のように上限を設定できます。

xdebug.max_nesting_level = 500

これをphpで直接修正することもできます。たとえば、プロジェクトの構成ファイルで修正できます。

ini_set('xdebug.max_nesting_level', 200);

php.ini構成ファイルに移動して、次の行を変更します。

xdebug.max_nesting_level=100

次のようなものに：

xdebug.max_nesting_level=200

PHP 5.59を使用するUbuntuの場合：
`：

/etc/php5/cli/conf.d

そのディレクトリでxdebug.iniを見つけます。私の場合は 20-xdebug.iniです。

この行を追加します `

xdebug.max_nesting_level = 200

またはこれ

xdebug.max_nesting_level = -1

-1に設定すれば、ネストレベルの値を変更する必要はありません。

`

xdebugが原因で発生した可能性があります。

「php.ini」の次の行にコメントして、サーバーを再起動してPHPをリロードしてください。

  ";xdebug.max_nesting_level"

/etc/php5/conf.d/を調べて、xdebug.iniというファイルがあるかどうかを確認してください

max_nesting_levelはデフォルトで100です

そのファイルに設定されていない場合は、以下を追加します。

xdebug.max_nesting_level=300

リストの最後に移動すると、次のようになります。

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

その後、この変更を行う前後に@Andreyのテストを使用して、機能するかどうかを確認できます。

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

php.ini：

xdebug.max_nesting_level = -1

値がオーバーフローして-1に達するかどうかは完全にはわかりませんが、-1に達しないか、max_nesting_levelがかなり高く設定されます。

再帰コードを反復コードに変換して、再帰をシミュレートできます。これは、リンクに到達したときに現在のステータス（URL、ドキュメント、ドキュメント内の位置など）を配列にプッシュし、このリンクが終了したときに配列からポップする必要があることを意味します。

ネスト関数呼び出しの数を増やす代わりに、（クラスターコンピューティングのように）並列ワーカーを実装することにより、ネストを小刻みに動かそうとすることができます。

例：限られた数のスロット（例：100）を定義し、それぞれに割り当てられた「ワーカー」の数を監視します。スロットが空くと、待機中のワーカーが「その中に」配置されます。

コマンドラインから再帰を確認します。

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

結果> 100の場合は、メモリ制限を確認します。

Laravelを使用している場合は、

composer update

これはうまくいくはずです。

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

PS 9999を任意の数に変更します。

多くのプラグインをインストールするときにエラーが発生したため、エラー100には、C：\ wamp \ www \ mysite \ wp-content \ plugins \ "..."をインストールした最後のプラグインの場所が含まれているため、このプラグインを削除しましたC：ドライブのフォルダーに移動すると、すべてが正常に戻りました。インストールするプラグインの数を制限するか、アクティブにしたと思います。

あなたの場合、それは間違いなくクローラーインスタンスがエラーをトレースし、情報をデバッグするためのより多くのXdebug制限を持っていることです。

しかし、他のケースでは、PHPのようなエラーやCodeIgniterライブラリのようなコアファイルがそのようなケースを作り出し、x-debugレベルの設定を増やしてもそれは消えません。

したがって、コードを注意深く調べてください:)。

これが私の場合の問題です。

CodeIgniterのライブラリであるサービスクラスがありました。このような機能を内蔵しています。

 class PaymentService {

    private $CI;

    public function __construct() {

        $this->CI =& get_instance();

   }

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

次のように私のコントローラー：

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

入力ミスのため、最後の行の関数呼び出しは間違っていましたが、代わりに以下のようになっているはずです：

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

その後、超過エラーメッセージが表示され続けました。しかし、私はXDebugを無効にしましたが、助けにはなりませんでした。とにかく、クラス名またはコードが適切な関数呼び出しかどうかを確認してください。

cloud9上のWordPressでこの問題が発生しました。それはW3キャッシングプラグインでした。プラグインを無効にしたところ、問題なく動作しました。

CLI（cmd）でPHPスクリプトを実行している場合の別の解決策

この場合、編集が必要なphp.iniファイルは異なります。私のWAMPインストールでは、コマンドラインで読み込まれるphp.iniファイルは次のとおりです。

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

phpがブラウザーから実行されたときにロードされる\ wamp \ bin \ apache \ apache2.4.9 \ bin \ php.iniの代わりに

オブジェクトへの再帰を制限するためにmodifier.debug_print_var.phpの{debug}関数を変更することもできます。

45行目あたり、前：

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

後：

$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));

この方法でも、Xdebugは通常どおりに動作します：var_dumpで再帰の深さを制限するなど。これは賢い問題なので、Xdebugの問題ではありません。

私は同じ問題を抱えていて、私はこのように愛しています：

MySQL my.iniファイルを開く

[mysqld]セクションで、次の行を追加します。innodb_force_recovery = 1

ファイルを保存してMySQLを起動してみてください

追加した行を削除して保存します