“Ölümcül hata: '100' maksimum işlev yuvalama düzeyine ulaşıldı, iptal edildi!” PHP'de

Bir html dosyasındaki tüm URL'leri bulan ve keşfedilen URL'lere bağlı her html içeriği için aynı işlemi tekrarlayan bir işlev yaptım. İşlev özyinelemelidir ve sonsuzca devam edebilir. Ancak, 100 özyinelemeden sonra özyinelemenin durmasına neden olan genel bir değişken ayarlayarak özyinelemeye bir sınır koydum.

Ancak, php bu hatayı döndürür:

Ölümcül hata: '100' maksimum işlev yuvalama düzeyine ulaşıldı, iptal edildi! D: \ wamp \ www \ crawler1 \ simplehtmldom_1_5 \ simple_html_dom.php 1355 satırında

Burada bir çözüm buldum: İç içe geçmiş işlev çağrı sınırını artırmak ama bu benim durumumda çalışmıyor.

Yukarıda belirtilen bağlantıdan cevaplardan birini alıntılıyorum. Lütfen düşünün.

"Zend, IonCube veya xDebug yüklü mü? Varsa, muhtemelen bu hatayı nereden alıyorsunuz demektir.

Ben birkaç yıl önce bu koştu, ve Zend PHP, orada bu sınırı koyarak sona erdi. Tabii ki kaldırmak 100 yinelemeyi geçmenize izin verecektir, ama sonunda bellek sınırlarına ulaşacaksınız. "

PHP maksimum işlev yuvalama düzeyini artırmak için bir yolu var mı

Değerini artırın xdebug.max_nesting_leveliçinde seninphp.ini

Basit bir çözüm sorunumu çözdü. Ben sadece bu satıra yorum yaptım:

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

Benim de php.inidosyaya. Bu uzantı yığını sınırlandırıyordu, 100bu yüzden devre dışı bıraktım. Özyinelemeli işlev şimdi beklendiği gibi çalışıyor.

Özyinelemeli işlev çağrıları yapmak yerine, yapıyı düzleştirmek için bir kuyruk modeliyle çalışın.

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

Bununla başa çıkmanın farklı yolları vardır. Geçilen başlangıç ​​noktası veya yollar hakkında bilgi edinmek istiyorsanız daha fazla bilgiyi takip edebilirsiniz. Benzer bir model üzerinde çalışabilecek dağıtılmış kuyruklar da vardır.

Başka bir çözüm xdebug.max_nesting_level = 200php.ini içine eklemek

Xdebug'u devre dışı bırakmak yerine, üst limiti aşağıdaki gibi ayarlayabilirsiniz:

xdebug.max_nesting_level = 500

Bunu doğrudan php'de, örneğin projenizin yapılandırma dosyasında düzeltmek de mümkündür.

ini_set('xdebug.max_nesting_level', 200);

Php.ini yapılandırma dosyanıza gidin ve aşağıdaki satırı değiştirin:

xdebug.max_nesting_level=100

gibi bir şeye:

xdebug.max_nesting_level=200

5.59 kullanarak Ubuntu üzerinde:
`:

/etc/php5/cli/conf.d

ve xdebug.ini dosyasını bu dizinde bul, benim durumumda 20-xdebug.ini

ve bu satırı ekleyin `

xdebug.max_nesting_level = 200

veya bu

xdebug.max_nesting_level = -1

-1 olarak ayarlayın ve iç içe geçme düzeyinin değerini değiştirmek için endişelenmenize gerek yok.

'

muhtemelen xdebug yüzünden oldu.

"Php.ini" dosyasında aşağıdaki satırı yorumlamayı deneyin ve PHP'yi yeniden yüklemek için sunucunuzu yeniden başlatın.

  ";xdebug.max_nesting_level"

Xdebug.ini adında bir dosya olup olmadığını görmek için /etc/php5/conf.d/ adresini aramayı deneyin.

max_nesting_level varsayılan olarak 100'dür

Bu dosyada ayarlanmamışsa şunu ekleyin:

xdebug.max_nesting_level=300

listenin sonuna kadar

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

daha sonra çalışıp çalışmadığını görmek için bu değişikliği yapmadan önce ve sonra @ Andrey testini kullanabilirsiniz .

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

php.ini:

xdebug.max_nesting_level = -1

Değerin hiç taşmayacağından ve -1'e ulaşacağından emin değilim, ama ya asla -1'e ulaşmayacak, ya da max_nesting_level oldukça yüksek olacak.

Özyinelemeli kodunuzu özyinelemeyi simüle eden yinelemeli bir koda dönüştürebilirsiniz. Bu, bir bağlantıya ulaştığınızda geçerli durumu (url, belge, belgedeki konum vb.) Bir diziye itmeniz ve bu bağlantı tamamlandığında diziden çıkarmanız gerektiği anlamına gelir.

Yuvalama işlevi çağrılarının sayısını artırmak yerine paralel çalışanlar (küme bilgi işleminde olduğu gibi) uygulayarak yuvalamayı hareket ettirmeye çalışabilirsiniz.

Örneğin: sınırlı sayıda yuva (örn. 100) tanımlarsınız ve her birine / bazılarına atanan "işçi" sayısını izlersiniz. Eğer herhangi bir yuva serbest kalırsa, bekleyen çalışanları "onlara" koyarsınız.

Komut satırından özyinelemeyi kontrol edin:

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

sonuç> 100 SONRA bellek sınırını kontrol edin;

Laravel kullanıyorsanız,

composer update

Bu iş olmalı.

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

PS 9999'u istediğiniz herhangi bir sayı ile değiştirin.

Birçok eklenti yüklerken bir hata aldım Yani 100 hatası C: \ wamp \ www \ sitem \ wp-content \ plugins \ "..." i yüklediğim son eklentinin konumu da dahil olmak üzere gösterdi, bu yüzden bu eklentiyi sildim klasöründe C: sürücü sonra her şey normale döndü. Ben yüklemek veya etkinleştirmek plug-in miktarını sınırlamak zorunda düşünüyorum. iyi şanslar umarım yardımcı olur

Sizin durumunuzda, tarayıcı örneğinin, hata ve hata ayıklama bilgilerini izlemek için daha fazla Xdebug sınırına sahip olması kesinlikle.

Ancak, diğer durumlarda PHP gibi hatalar veya CodeIgniter kütüphaneleri gibi çekirdek dosyalar da böyle bir durum yaratır ve hatta x-debug seviye ayarını artırırsanız bile kaybolmaz.

Bu yüzden, kodunuza dikkatlice bakın :).

Benim durumumda sorun buydu.

CodeIgniter kitaplığı olan bir hizmet sınıfı vardı. İçinde böyle bir işlev var.

 class PaymentService {

    private $CI;

    public function __construct() {

        $this->CI =& get_instance();

   }

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

Benim denetleyicisi aşağıdaki gibi:

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

Son satırdaki işlev çağrısı yazım hatası nedeniyle yanlıştı, bunun yerine aşağıdaki gibi olmalıydı:

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

Sonra aşmak hata mesajı almaya devam ediyordu. Ama XDebug devre dışı bırakıldı ama yardım etmedi. Herhangi bir şekilde, uygun işlev çağrısı için sınıf adını veya kodunuzu kontrol edin.

Cloud9'da WordPress ile bu sorunu yaşadım. W3 Caching eklentisi olduğu ortaya çıktı. Eklentiyi devre dışı bıraktım ve iyi çalıştı.

CLI (cmd) php betiği çalıştırıyorsanız başka bir çözüm

Bu durumda düzenleme gerektiren php.ini dosyası farklıdır. WAMP kurulumumda komut satırına yüklenen php.ini dosyası:

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

php tarayıcıdan çalıştırıldığında yüklenen \ wamp \ bin \ apache \ apache2.4.9 \ bin \ php.ini yerine

Yinelemeyi nesnelere sınırlamak için modifier.debug_print_var.php dosyasındaki {debug} işlevini de değiştirebilirsiniz.

45 yaşından önce, önce:

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

Sonra:

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

Bu şekilde, Xdebug hala normal davranacaktır: var_dump ve benzeri yineleme derinliğini sınırlandırın. Bu akıllıca bir sorun olduğundan, Xdebug değil!

Ben de aynı sorunu vardı ve ben böyle reslove:

MySQL my.ini dosyasını açın

[Mysqld] bölümünde şu satırı ekleyin: innodb_force_recovery = 1

Dosyayı kaydedin ve MySQL'i başlatmayı deneyin

Yeni eklediğiniz satırı kaldırın ve Kaydet