Fatal error a1007 nesting level too deep

I have a complex hierarchy of nested objects, with all of the child objects (stored an array of objects in the parent class) containing a property linking back to their parent: fairly simple and straightforward, with no real problems. If I do a var_dump of any object in the hierarchy, I’ll get a recursive reference in the dump, exactly as I’d expect.

FIRSTGEN 
   _children array of objects of type SECONDGEN
      SECONDGEN #1
         _parent object of type FIRSTGEN
         _children array of objects of type THIRDGEN
            THIRDGEN #1
               _parent object of type SECONDGEN
            THIRDGEN #2
               _parent object of type SECONDGEN
      SECONDGEN #2
         _parent object of type FIRSTGEN
         _children array of objects of type THIRDGEN
            THIRDGEN #3
               _parent object of type SECONDGEN

I’ve recently added some new elements to that hierarchy, and they don’t follow quite the same pattern. They are stored in an array of objects in the top-level parent, but contain a property linking them back, not to their parent, but to a sibling. When I do a var_dump now, I get a «Fatal error: Nesting level too deep — recursive dependency?».

FIRSTGEN 
   _children_1 array of objects of type SECONDGEN_1
      SECONDGEN_1 #1
         _parent object of type FIRSTGEN
         _children array of objects of type THIRDGEN
            THIRDGEN #1
               _parent object of type SECONDGEN_1
            THIRDGEN #2
               _parent object of type SECONDGEN_1
      SECONDGEN_1 #2
         _parent object of type FIRSTGEN
         _children array of objects of type THIRDGEN
            THIRDGEN #3
               _parent object of type SECONDGEN_1
   _children_2 array of objects of type SECONDGEN_2
      SECONDGEN_2 #1
         _parent object of type SECONDGEN_1

Everything else within the code works correctly, with the exception of that var_dump(). I’ve tried creating a simpler example to demonstrate the problem, so that I could provide an example when asking this question; but haven’t been able to replicate it in a short test, only within my more complex code.

I know that the solution is to refactor the relationship so that my _children_2 array of SECONDGEN_2 objects is held in the appropriate SECONDGEN_1 parent, making the parent relationship «correct»… I’ve already started doing this.
However, I’m intrigued by the error, and wondered if anybody else had encountered it (and how you dealt with it yourself).

У меня сложная иерархия вложенных объектов со всеми дочерними объектами (хранящимися в массиве объектов в родительском классе), содержащими свойство, связывающееся с их родительским классом: довольно просто и понятно, без реальных проблем. Если я сделаю var_dump любого объекта в иерархии, я получу рекурсивную ссылку в дампе, как и ожидал.

FIRSTGEN 
   _children array of objects of type SECONDGEN
      SECONDGEN #1
         _parent object of type FIRSTGEN
         _children array of objects of type THIRDGEN
            THIRDGEN #1
               _parent object of type SECONDGEN
            THIRDGEN #2
               _parent object of type SECONDGEN
      SECONDGEN #2
         _parent object of type FIRSTGEN
         _children array of objects of type THIRDGEN
            THIRDGEN #3
               _parent object of type SECONDGEN

Недавно я добавил в эту иерархию несколько новых элементов, и они не следуют той же схеме. Они хранятся в массиве объектов в родительском элементе верхнего уровня, но содержат свойство, связывающее их обратно не с их родителем, а с братом или сестрой. Когда я делаю var_dump сейчас, я получаю сообщение «Неустранимая ошибка: слишком глубокий уровень вложенности — рекурсивная зависимость?».

FIRSTGEN 
   _children_1 array of objects of type SECONDGEN_1
      SECONDGEN_1 #1
         _parent object of type FIRSTGEN
         _children array of objects of type THIRDGEN
            THIRDGEN #1
               _parent object of type SECONDGEN_1
            THIRDGEN #2
               _parent object of type SECONDGEN_1
      SECONDGEN_1 #2
         _parent object of type FIRSTGEN
         _children array of objects of type THIRDGEN
            THIRDGEN #3
               _parent object of type SECONDGEN_1
   _children_2 array of objects of type SECONDGEN_2
      SECONDGEN_2 #1
         _parent object of type SECONDGEN_1

Все остальное в коде работает правильно, за исключением var_dump (). Я попытался создать более простой пример, чтобы продемонстрировать проблему, чтобы я мог привести пример, задав этот вопрос; но не смог воспроизвести это в коротком тесте, только в моем более сложном коде.

Я знаю, что решение состоит в том, чтобы реорганизовать отношение так, чтобы мой массив _children_2 объектов SECONDGEN_2 содержался в соответствующем родительском элементе SECONDGEN_1, делая родительское отношение «правильным»… Я уже начал это делать. Тем не менее, я заинтригован этой ошибкой и задаюсь вопросом, сталкивался ли с ней кто-нибудь еще (и как вы сами с ней справились).

This error message appears on every script, even in this one:

<? ?>

This is just as it looks at the end of ANY php page:

"Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0"

Environment:

RedHat Linux8.0 Kernel 2.4.18-14 
Apache 2.0.40
PHP 4.3.0

And this is how I compiled PHP:

./configure i386-redhat-linux 
  --with-apxs2=/usr/sbin/apxs 
  --with-config-file-path=/etc 
  --with-gd 
  --with-zlib 
  --enable-ftp 
  --with-mysql 
  --with-informix=/opt/informix 
  --enable-sockets

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports

Please run a "make test" after compiling PHP with "make" in the source directory and press "y" if it asks to send the information to the QA site.

Derick

Unfortunately I can not send the "make test" results because the company where I work has too much restrictive firewall rules (paranoid grade): Form upload limits, no pop3 clients, password protected proxy, ...

All that I can currently tell you is that I have the same problem even with a much simpler PHP configuration:

./configure i386-redhat-linux 
  --with-apxs2=/usr/sbin/apxs 
  --with-config-file-path=/etc

I'm seeing the same problem with a very similar config:
RH8.0, php4-STABLE-200301020430 even running the
command line tool gives this result, so I believe this is
independent of the apache version:

echo "<?php ?>" | ./php

Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0

I did a make test and submitted it to QA.  I hope this helps.

Okay, I solved my own problem with a little help from a comment in bug 21206.  My /etc/php.ini file was pointing to the RedHat-supplied modules in /usr/lib/php4.  I was able to fix the problem by changing the line in /etc/php.ini that says:

extension_dir = /usr/lib/php4

to point to the new location of the modules.  This is where the imap.so, ldap.so, mysql.so, etc are.  Alternatively, you could copy the newly-compiled modules from the compile-directory/modules up to /usr/lib/php4.

Now, mine works perfectly.

Me too, with Apache 1.3.27, y php 4.3.0 using php-nuke 6.0

My solution:

editing php.ini:

change this line:
extension_dir = /usr/lib/php4

for this:
extension_dir = /usr/lib/php

best regards from spain (barcelona)

bye
alex

I rna the make test and received the same error????  Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0

I have checked and the modules imap.so and ldap.so do appear in the usr/lib/php4 directory and since the installation of PHP was new they cannot be old version. This is on a red hat 8 with php 4.3.1

This happens with me as well, with a virgin install of phpBB2 on Libranet 2.8.1 (Debian Sarge, Kernel 2.4.21).  Apache 1.3.29.

RedHat Linux9 
Apache 2.0.41
PHP 4.3.1

I've copied the newly-compiled modules in /etc/php4 and everithing is ok

Bye from Rome

Simone