Description: ------------ When generating the API docs for Horde's framework module, we get the following error each time: php in malloc(): warning: recursive call FATAL: emalloc(): Unable to allocate 129 bytes All other modules work fine, and even the API docs seem to be generated correctly. This happened since ever, it's nothing that was introduced with RC6. I justed tested on a Linux system, and there I get a fatal error due to exceeding memory_limit during "Processing Procedural Page Element Name Conflicts": Sorting page elements...done Formatting @uses list...Building indexes... Fatal error: Allowed memory size of 268435456 bytes exhausted at /home/jan/cvs/p hp44/Zend/zend_hash.c:275 (tried to allocate 52 bytes) in /usr/share/php/PhpDocu mentor/phpDocumentor/Converter.inc on line 1474 Call Stack: 0.0003 14736 1. {main}() /usr/bin/phpdoc:0 0.0008 22568 2. include() /usr/bin/phpdoc:37 0.2282 7522336 3. phpdocumentor_setup->createdocs() /usr/share/php/PhpD ocumentor/phpDocumentor/phpdoc.inc:62 517.5416 237710696 4. phpdocumentor_intermediateparser->output() /usr/share /php/PhpDocumentor/phpDocumentor/Setup.inc.php:672 528.7395 251154104 5. phpdocumentor_intermediateparser->_setupuseslist() /u sr/share/php/PhpDocumentor/phpDocumentor/IntermediateParser.inc:1764 528.7397 251195072 6. __dummyconverter->_createpkgelements() /usr/share/php /PhpDocumentor/phpDocumentor/IntermediateParser.inc:1500 Test script: --------------- The command being used is: phpdoc -d framework -t api -i CVS/\* -o "HTML:frames:phphtmllib" -ti "framework" -dn horde -dc horde --pear The framework module can be checked out from Horde's CVS server (http://horde.org/source/) or downloaded as a snapshot (framework-HEAD-...tar.gz from http://ftp.horde.org/pub/snaps/latest/).

is there any chance of a test script smaller than horde? :)

This looks too me like standard phpDocumentor memory usage on large code bases. There might well be optimizations to make but the only short term fix i see is too not set a memory_limit of 256M in Setup.inc.php

> is there any chance of a test script smaller than horde? Of course, but then the memory_limit wouldn't be hit. ;)

> This looks too me like standard phpDocumentor memory usage on large code > bases. There might well be optimizations to make but the only short > term fix i see is too not set a memory_limit of 256M in Setup.inc.php Even a limit of 512M didn't suffice, some optimization seems really necessary.

I don't think this is a case of simple optimizations. We started some work on a branch that uses sqllite for data storage that will get around this problem. Base PHP data structures are efficient and in a large app like this its really easy to get things in a state where no memory is released until PHP stops. I would expect something like Horde to use around a gig of ram. Memory optimizations patches are welcome, but I think on the current codebase you could spend days tweaking stuff without getting any results.

would it be possible not to overwrite the memory limit settings in case the initial value (php.ini) is higher than 256MB? (Setup.inc.php) i would prefer not to change the source code and to have the change to increase the allowed memory size...

I have this problem. Obviously no one is planning no fixing it. However there is an interim fix. Its outlined here. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375070 Basically just edit /usr/bin/pecl and add "-d memory_limit=-1" to the php command on the last line I think this would be the most elegant fix, for now.

I submitted a Sourceforge patch last month that allows you to configure a max memory value in the phpDocumentor.ini file. The patch is at https://sourceforge.net/tracker/index.php?func=detail&aid=1588942&group_id=11194&atid=311194 Here's how it works: - if you put a memory_limit value in phpDocumentor.ini, it is used... period... regardless of how big or how small in relation to php.ini or 256; - otherwise, the LARGER of php.ini's value OR the 256MB value is used. Oliver: If your php.ini setting is already >256, then the existing code should not be causing phpDocumentor to drop to the lower 256MB ceiling. However, using my patch will allow you to set the value to whatever you want it to be, using phpDocumentor.ini to do it.

Greg, should I consider committing patch #1588942 as a "fix" for this particular bug, or would that patch count as an enhancement ("feature") and require this bug to wait for a feature release before it gets committed?

the patch simply allows setting memory_limit, which does not in fact improve memory usage, so no, this is a separate and massive undertaking that is planned for 2.0

SF patch #1588942 is now committed to CVS, so memory_limit will now be configurable in the INI file.

Sorry to add to an old thread, but I was quiet surprised to see this still an issue 4 years after it was reported. Even at a 1GB of ram, it's still failing to parse out the documentation. This only started happening after recompiling with tokenizer support, because it was failing for different reasons with out.

I have the same problem (allowed memory size exhausted) while trying to generate the documentation of my models, generated by Propel (113 model classes, with their peers, map builders and base classes - 565 files). Ubuntu 9.10 PHP 5.2.10-2ubuntu6.4 with Suhosin-Patch 0.9.7 (cli) Zend Engine v2.2.0 with Xdebug v2.0.4 phpDocumentor version 1.4.3 Maximum memory usage set at 512M by phpDocumentor.ini using tokenizer Parser [exec] Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 35 bytes) in /usr/share/php/PhpDocumentor/phpDocumentor/phpDocumentorTWordParser.inc on line 303 [exec] [exec] Call Stack: [exec] 0.0006 57828 1. {main}() /usr/bin/phpdoc:0 [exec] 0.0011 66360 2. require('/usr/share/php/PhpDocumentor/phpDocumentor/phpdoc.inc') /usr/bin/phpdoc:40 [exec] 0.1359 9419524 3. phpDocumentor_setup->createDocs() /usr/share/php/PhpDocumentor/phpDocumentor/phpdoc.inc:65 [exec] 107.1463 533144076 4. phpDocumentorTParser->parse() /usr/share/php/PhpDocumentor/phpDocumentor/Setup.inc.php:752 [exec] 107.1516 530961380 5. phpDocumentorTParser->configWordParser() /usr/share/php/PhpDocumentor/phpDocumentor/phpDocumentorTParser.inc:235 [exec] 107.1517 530961444 6. phpDocumentorTWordParser->setup() /usr/share/php/PhpDocumentor/phpDocumentor/phpDocumentorTParser.inc:2939 [exec] 107.1639 534709464 7. phpDocumentorTWordParser->addFileSource() /usr/share/php/PhpDocumentor/phpDocumentor/phpDocumentorTWordParser.inc:124 [exec] 107.2731 536752240 8. phpDocumentorTWordParser->addSource() /usr/share/php/PhpDocumentor/phpDocumentor/phpDocumentorTWordParser.inc:282 [exec] 107.2731 536752832 9. str_replace() /usr/share/php/PhpDocumentor/phpDocumentor/phpDocumentorTWordParser.inc:303 [exec] [exec] Result: 255 (running with Ant)

What I am missing from this discussion is WHY? WHY is memory usage so outrageous. I am compiling documentation for openbiz some 168764 lines of code in 695 files This consumes 580M of memory. That comes to ~1M per file and 3.6Kb per line of code! Surely this can be done much more efficient with less memory. Maybe its worth investigating where memory is used, where memory can be released etc...

An option to consider -- http://thorie.com/blog/phpdocumentors-memory-usage.htm

No more feature work on phpDocumentor 1.x. Check out the new phpDocumentor 2.x (http://www.phpdoc.org/).