Description: ------------ I noticed while running PhpDoc against itself (CVS HEAD), that when using PHP v5.2.1 it consistently hangs at the "Converting tutorials/extended docs" stage. It still eats all my CPU and continues to consume RAM, up to the memory_limit before dying. I verified this happens using PhpDoc v1.3.1 against PHP v5.2.1 also. Further, I verified this does NOT happen with PHP v5.2.0 nor any earlier PHP versions I try (5.1.6, 4.4.6). Something about PHP v5.2.1 doesn't like PhpDoc's tutorials... or perhaps it's something about the first task it attempts ("Converting Top-level Class-level tutorial Converter.cls").

I'm using the PHP v5.2.1 zipfile that I downloaded from php.net (http://www.php.net/get/php-5.2.1-Win32.zip/from/a/mirror), so I didn't compile it myself. The one thing I have noticed about this zipfile from php.net compared to previous ones I gotten from there is that memory_limit can be modified... which tells me that "--enable-memory-limit" was compiled in, which in and of itself seems odd to me. Perhaps it's that list of compile options that will ultimately explain this bug.

I have tried to change the memory limit up to 512MB and it still hangs at that step!

Dario, are you using PHP v5.2.1 also? Did you compile it yourself or did you get the binary from php.net?

I pulled in the PHP v5.2.1 source and compiled it myself, just a vanilla compile (./configure, make, make install, no extra options). The only thing extra I did do was patch two files to get it to compile on WinXP/Cygwin (PHP bug 40488 http://bugs.php.net/bug.php?id=40488). So, this bug occurs with both the provided Windows binary at php.net as well as a vanilla self-compile from source.

Hello Chuck! Yes I am using PHP 5.2.1. But I got the binary files from php.net (more precisely .msi file).

Looks like it's getting into an endless loop inside ParserElements.inc in parserTutorial->isChildOf() for the parserTutorial object $name=phpDocumentor.quickstart.pkg. This endless loop does _not_ occur using PHP v5.2.0, so I assume that means perhaps a command that is used in isChildOf() was changed from 5.2.0 to 5.2.1...

Speaking of the memory_limit being compiled in or not... I see that item #4 of PHP v5.2.0's "features" is: - memory-limit is always enabled (--enable-memory-limit removed) (http://www.php.net/ChangeLog-5.php#5.2.1) Looks like they've made that option permanently "compiled in".

I have the problem isolated to the FOREACH loop in the Converter->_processTutorials() method (Converter.inc), the one that calls parserTutorial->isChildOf() (ParserElements.inc), but I don't have a clue why it's doing what it's doing. The $parents array has seven objects in it, and once the FOREACH reaches its last iteration (i = 6), suddenly i=3, and it then runs 3..6 again, jumps back to 3 again, and away we go. Why would a loop this simple work in 5.2.0 but not in 5.2.1?

Hi Chuck, I think you may have found a serious bug in the implementation of foreach in PHP 5.2.1. isChildOf() iterates over $parents. I suspect that these commits: http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_compile.c?r1=1.647.2.27.2.25&r2=1.647.2.27.2.26 http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_language_parser.y?r1=1.160.2.4.2.2&r2=1.160.2.4.2.3 are responsible for the break, but have no idea what they do.

I think I found the source of the bug: http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_compile.c?annotate=1.647.2.27.2.26#l3791 This line is subtracting 3 from the opcode. Apparently something phpDocumentor is doing with the double foreach() is causing it to reset the *counter* by 3. The coincidence is too suspicious to be a simple one. If I'm right, this simple PHP probably reproduces the endless loop (I'm on the road with no time to set up PHP 5.2.1 right now): <?php $a = array(1,2,3,4,5,6); function iter($arr) { foreach ($arr as $i => $variable) { if ($i == 5) { return true; } } } foreach ($a as $i => $parent) { if ($i == 5) { iter($a); } } ?> The reason for the regression may be that the endforeach code is never executed because we execute the foreach via return in the function scope, but since I can't test it, I can't be sure. Can you try that test script Chuck?

Greg's test script works fine on 5.2.1 on my windows laptop and on bluga.net

In the PhpDoc code, there is an outermost foreach iterating through an array of objects. In the loop, it's calling an object's member function. That member function has its own outer foreach and inner foreach, and it will choose to do a premature return from inside the inner foreach. That MIGHT mean there are two foreach's not reaching their end nor continue/breaking out. Josh, if you're still at your box, try wrapping one more foreach around the the one that is returning a true in Greg's script.

I'm not sure if I understand what you mean, I added an extra foreach and it didn't make a difference.

I spent a while this morning trying to perfect Greg's example to trigger the problem, with no success. I dug around the PHP buglist and found this PHP #40608. It sounds exactly light what's happening, and it was closed due to no feedback. I've reopened it, adding what info I can from my experience of the problem.

PHP developer tony2001@php.net indicates the example code on PHP bug 40608 works perfectly on several Linux/Unix variants, but doesn't mention Windows. I'm not too sure they're willing to pursue testing it on Windows...

The example code on PHP bug 40608 is working properly on the PHP v5.2 snapshot from today (php5.2-win32-200703191630.zip). So, the PHP issue seems to be corrected already. I'm testing PhpDocumentor against that PHP snapshot now to ensure this issue is cleared up...

IT WORKS! Woohoo! So, guys, what's the proper way to warn the PhpDoc users to avoid PHP v5.2.1?

Also, what's the proper way to close this bug, since the problem is a PHP bug but will still wreak havoc on PhpDoc for the unwary who run it on PHP v5.2.1?

The proper way is to add an <exclude>5.2.1</exclude> into the <php> dependency in package.xml, and to put a notice in the RELEASE-1.3.2 notes for sourceforge uesrs

In my testing of this, the problem only manifests itself when the source code includes tutorials to be processed. Will that "exclude" tag effectively enforce "no 5.2.1 at all", or is there a less strict way to say "works in 5.2.1 but do not use with tutorials due to infinite loop PHP bug"?

in this case, we need to add a check in the source code itself, and if there are tutorials, simply die if we're using PHP 5.2.1 with an explanation. Then, we need to put this is bold print on the front page of phpdoc.org, and in the release notes of package.xml and RELEASE-1.3.2

See if this patchset is to your liking... I've made a generic error code for recognized PHP bug conditions, and a standalone function to check for a known version/bug condition. This is set up in the Errors and Setup patches. I simply call this function from the start of the parserTutorial::isChildOf() method, to check for this specific bug.

Updated the constant value of the error code in Errors-patch to "80"... I'm already using "79" in another waiting-to-be-accepted patch.

Chuck/Greg, I have been tearing my hair out today trying to run down a problem that sounds like the same thing here. However, my case does not match the one you describe. Short version: I can duplicate this issue in PHP 5.1.1, as well. I am running PHPdoc v. 1.3.1 (downloaded earlier today in my attempts to iron this out, I'm sorry that I don't recall the specific earlier version number which was also failing, though in slightly different form) on PHP 5.1.1 on my WinXP machine. I get "Trying to get property of a non-object" notices, like your #9915. Eventually, it blows through that serries of notices and fetches up at "Generating PDF file.....", where it hangs. It's been eating 95-99% of my CPU and ~120 meg of memory for the last three hours. Sorry to complicate things for you. It was much nicer when it was just a single version.

If you're running PhpDocumentor against a medium/large codebase, then you don't want to use the PDF converter (see release notes for every release since 1.2.2... look for "speaking of speed"). That converter code seems to be inefficient enough to get noticeably worse as your codebase size increases.

This fix has been committed to the CVS Head as well as the v.1.3.2 release branch.