Htmlファイル内のすべてのURLを見つけて、発見されたURLにリンクされている各htmlコンテンツに対して同じプロセスを繰り返す機能を作りました。この関数は再帰的であり、際限なく続くことがあります。しかし、100回の再帰の後に再帰が停止するようにするグローバル変数を設定することによって、再帰に制限を加えました。
しかし、phpはこのエラーを返します。
致命的なエラー: '100'の最大関数ネストレベルに到達しました、中止しました! 1355行目のD:\ wamp\www\crawler1\simplehtmldom_1_5\simple_html_dom.php
私はここで解決策を見つけました: 増加するネスト関数呼び出し制限 しかしこれは私の場合はうまくいきません。
上記のリンクから答えの1つを引用しています。ご検討ください。
「Zend、IonCube、xDebugのいずれかがインストールされていますか?インストールされている場合、おそらくそれがこのエラーの原因です。
私は数年前にこれに遭遇しました、そしてそれはZendがPHPではなくその限界をそこに置くことになった。もちろんそれを削除することで100回の反復を過ぎることになりますが、やがてメモリの限界に達するでしょう。」
PHPの最大関数ネストレベルを上げる方法はありますか
簡単な解決策が私の問題を解決しました。私はちょうどこの行をコメントしました:
zend_extension = "d:/wamp/bin/php/php5.3.8/zend_ext/php_xdebug-2.1.2-5.3-vc9.dll
私のphp.ini
ファイルに。この拡張はスタックを100
に制限していたので、私はそれを無効にしました。再帰的機能は現在期待通りに機能しています。
xdebug.max_nesting_level
の php.ini
の値を増やしてください
再帰的な関数呼び出しではなく、キューモデルを使って構造を平坦化します。
$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;
}
それを処理するにはさまざまな方法があります。原点や通過した経路に関する洞察が必要な場合は、より多くの情報を追跡できます。同様のモデルで動作できる分散キューもあります。
他の解決策はphp.iniにxdebug.max_nesting_level = 200
を追加することです。
Xdebugを無効にするのではなく、次のように上限を設定できます。
xdebug.max_nesting_level = 500
プロジェクトの設定ファイルなど、phpで直接修正することも可能です。
ini_set('xdebug.max_nesting_level', 200);
/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's testを使ってうまくいくかどうかを確認できます。
php -r 'function foo() { static $x = 1; echo "foo ", $x++, "\n"; foo(); } foo();'
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"
php.ini:
xdebug.max_nesting_level = -1
値がオーバーフローして-1に達するかどうかは完全にはわかりませんが、-1に達しないか、またはmax_nesting_levelをかなり高く設定することになります。
ネスティング関数呼び出しの数を増やすのではなく、(クラスタコンピューティングのように)並列ワーカーを実装することで、ネスティングを細かくすることができます。
例えば:あなたは限られた数のスロット(例えば100)を定義し、それらのそれぞれ/いくつかに割り当てられた「ワーカー」の数を監視します。いずれかのスロットが空いたら、あなたは待っている労働者を「彼らの中に」入れます。
再帰的なコードを反復的なコードに変換して、再帰をシミュレートすることができます。つまり、リンクに到達したら現在のステータス(URL、ドキュメント、ドキュメント内の位置など)を配列にプッシュし、このリンクが終了したら配列からポップする必要があります。
コマンドラインから再帰をチェックします。
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 ...
P.S 9999を任意の番号に変更します。
オブジェクトへの再帰を制限するために、modifier.debug_print_var.phpの{debug}関数を修正することもできます。
45行目の前、
$results .= '<br>' . str_repeat(' ', $depth * 2)
. '<b> ->' . strtr($curr_key, $_replace) . '</b> = '
. smarty_modifier_debug_print_var($curr_val, ++$depth, $length);
後:
$max_depth = 10;
$results .= '<br>' . str_repeat(' ', $depth * 2)
. '<b> ->' . 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の問題ではありません。
あなたの場合は間違いなくクローラーインスタンスはエラーとデバッグ情報をトレースするためにより多くの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 Cachingプラグインだったことがわかりました。私はプラグインを無効にし、それはうまくいきました。
この場合、編集が必要なphp.iniファイルは異なります。私のWAMPインストールでは、コマンドラインにロードされるphp.iniファイルは以下の通りです。
\wamp\bin\php\php5.5.12\php.ini
ブラウザからphpを実行したときに読み込まれる\ wamp\bin\Apache\apache2.4.9\bin\php.iniの代わりに
私は多くのプラグインをインストールしていたときに私はエラーがあったので、エラー100は私がCをインストールした最後のプラグインの場所を含むことを示した:\ wamp\www\mysite\wp-content\plugins\"..." C上のフォルダ:ドライブそれからすべてが正常に戻りました。