I have a Symfony2 project with some functional tests.
When I run the test suite without code coverage enabled, there is no problem.
But when I am trying to generate the code coverage I am getting a PHP Fatal error :
Generating code coverage report, this may take a moment.
PHP Fatal error: Allowed memory size of 209715200 bytes exhausted
(tried to allocate 79 bytes) in /usr/share/php/PHP/Token/Stream.php on line 205
PHP Stack trace:
PHP 1. {main}() /usr/bin/phpunit:0
PHP 2. PHPUnit_TextUI_Command::main() /usr/bin/phpunit:46
PHP 3. PHPUnit_TextUI_Command->run() /usr/share/php/PHPUnit/TextUI/Command.php:130
PHP 4. PHPUnit_TextUI_TestRunner->doRun() /usr/share/php/PHPUnit/TextUI/Command.php:192
PHP 5. PHP_CodeCoverage_Report_HTML->process() /usr/share/php/PHPUnit/TextUI/TestRunner.php:373
PHP 6. PHP_CodeCoverage->getReport() /usr/share/php/PHP/CodeCoverage/Report/HTML.php:133
PHP 7. PHP_CodeCoverage_Report_Factory->create() /usr/share/php/PHP/CodeCoverage.php:141
PHP 8. PHP_CodeCoverage_Report_Factory->addItems() /usr/share/php/PHP/CodeCoverage/Report/Factory.php:76
PHP 9. PHP_CodeCoverage_Report_Factory->addItems() /usr/share/php/PHP/CodeCoverage/Report/Factory.php:98
PHP 10. PHP_CodeCoverage_Report_Node_Directory->addFile() /usr/share/php/PHP/CodeCoverage/Report/Factory.php:94
PHP 11. PHP_CodeCoverage_Report_Node_File->__construct() /usr/share/php/PHP /CodeCoverage/Report/Node/Directory.php:211
PHP 12. PHP_CodeCoverage_Util::getLinesToBeIgnored() /usr/share/php/PHP/CodeCoverage/Report/Node/File.php:166
PHP 13. PHP_Token_Stream_CachingFactory::get() /usr/share/php/PHP/CodeCoverage/Util.php:254
PHP 14. PHP_Token_Stream->__construct() /usr/share/php/PHP/Token/Stream/CachingFactory.php:68
PHP 15. PHP_Token_Stream->scan() /usr/share/php/PHP/Token/Stream.php:147
I already modified memory_limit for both cli and server php.ini.
I also already modified the memory_limit of suhosin.
When I print a phpinfo() in the cli I got these values :
memory_limit => 2048M => 2048M
suhosin.memory_limit => 2G => 2G
Does anyone has an idea of what may be causing this problem ? Has anyone faced such a situation ?
Looks like it stops at 200 Megabytes so either you need to look through your config more to allow more memory to be used or you have an include loop somewhere in the code. This has happened to me with twig includes a couple of times
Increase your PHP Memory Limit (I used 1744M to leave some safety space for PHP). I had the same problem before doing the extra memory. The next thing I changed was to exclude external libraries from the code-coverage (they are tested in their package by the author, so I do not need to know their code-coverage in my project). This allowed our project to then parse properly and get proper code coverage analysis.
Related
Facing an issue in excel sheet & CSV reader with large quantities of records in Codeignitor.
A PHP Error was encountered
Severity: Warning
Message: simplexml_load_string(): Memory allocation failed : growing buffer
Filename: Reader/Excel2007.php
Line Number: 645
Backtrace:
File: \application\third_party\PHPExcel\Reader\Excel2007.php
Line: 645
Function: simplexml_load_string
File: \application\controllers\admin\Csv.php
Line: 56
Function: load
File: \index.php
Line: 322
Function: require_once
The first option is to increase memory for php with the setting in the file php.ini.
memory_limit = 256M
The number can be lower and different but should be at least higher then it's now, but surely it can be higher than 256M too.
After the change perhaps the sever has to be restarted (depends on some things).
If that doesn't help, then it's worth it to look at the application and even the CSV-file.
Basic problem concerning most frameworks is that data are collected, hold in memory, parsed and then the results are shown or written in the database if applying.
Programs for big data have somehow to chunk the data and that also can mean just to streamline and processing step by step (like a video or soundfile).
As XMLis no stream-format but requires a fully parsed structure before it's processed usually the hint might look a bit useless. But perhaps there are a few things you could do to reduce the data-amount to be processed at once:
If simplexml is used to process several files at once it should be easy just to reduce the amount of files.
if the XML-file(s) are just too large you've to produce smaller files. It's also possible to split files but a little bit knowledge about XML is required for it.
In general it's possible that small tweaks at the implementation in CodeIgniter could solve the problem already, but as that one is unknown here we can only guess about it.
To increase PHP memory limit setting, edit your PHP.ini file. Simply increase the default value (example: Maximum amount of memory a script may consume = 128MB) of the PHP memory limit line in php.ini.
memory_limit = 256M
Alternatively you can edit your .htaccess file.
php_value memory_limit 256M
Note: If you don’t have access to these files or lack the experience to make this change, you can contact your web host and ask them to increase your PHP memory limit.
The original installation was on Ubuntu 14.04 with PHP 5.5.9 and CakePHP 5.4.1. After migrating to Ubuntu 16.04 with PHP 7.0.30 I updated CakePHP to 2.10.4 mainly by exchanging the lib folder. Everything works fine in the web interface, even the memory consuming tasks of the application.
But the CLI is broken. Every call to 'app/Console/cake' throws a 'PHP Fatal error'.
root#watt18:/var/www_external/app# Console/cake bake
PHP Fatal error: Allowed memory size of 2097152 bytes exhausted (tried to allocate 8192 bytes) in /var/www_external/lib/Cake/Console/ConsoleOptionParser.php on line 510
PHP Fatal error: Allowed memory size of 2097152 bytes exhausted (tried to allocate 32768 bytes) in /var/www_external/lib/Cake/I18n/I18n.php on line 1
The 'in' part changes from call to call. Searching the web I could not find any comparable topic. I checked the persmissions on all the folders inside 'app' but could not find any differences to the original installation. I tried to debug but couldn't get really far yet. Up to the line return ShellDispatcher::run($argv); in Console/cake.php everything is fine.
I get the same result when making a call inside the original cakephp folder from a fresh download.
I have no idea where all the memory gets lost.I would be happy about any hint to what might cause the problem or how to continue with debuging.
set memory_limit = -1 in your php.ini
but this is not a good solution , you may have a memory leake somewhere
please double check your statements , specialy if there is a loop with many memory usage
I am trying to migrate a database from an old XP machine to a new Synology DS213. I successfuly imported the database and mirrored permissions, but am having trouble actually getting the website to work. I run out of memory no matter how high I raise the max memory limit.
I was able to install the xdebug extention to help me debug. I have tryied I quickly run out of memory with the following error: (this is just the first couple of lines)
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried
to allocate 70987243 bytes) in /volume1/web/includes/phpFunctions.php
on line 203 Call Stack: 0.0011 324280 1. {main}()
/volume1/web/index.php:0 0.0024 324728 2.
require('/volume1/web/includes/phpFunctions.php')
/volume1/web/index.php:14 0.0646 337424 3. phpMySQL->dbQuery()
/volume1/web/includes/phpFunctions.php:35 0.0653 337568 4.
phpMySQL->stopProcess() /volume1/web/includes/db/mySQL.php:69 0.0655
337968 5. myErrorHandler() /volume1/web/includes/db/mySQL.php:254
0.0662 343400 6. raiseError() /volume1/web/includes/phpFunctions.php:160 0.0670 344608 7.
phpMySQL->dbQuery() /volume1/web/includes/phpFunctions.php:209 0.0678
345792 8
I am at a loss. I don't expect anyone to solve it for me, but hopefully point me in the right direction to learn more about the errors.
Try add this line to your script (possibly in index.php) -
#ini_set('memory_limit', '1G');
If this doesn't work then try import database again in this way - first import 2/3 table then again next 2/3 table and so on and also make sure that there is no infinite loop(s).
I have set my PHP MAMP server to a maximum of "256M" in the php.ini but am suddenly getting a memory error. There are two things that are strange about this:
This is a shockingly high amount of memory for a script to use. Maybe I'm too easily shocked but should scripts be running over 256M? I wouldn't have thought so.
Even though I've now changed my setting to "512M" I still get the memory error and it still reports running out in/around the 256M range (as if my setting is being ignored). I did recycle the web server which I figured would be enough to get the new settings into play.
The exact message I'm getting is this:
[25-Oct-2012 14:27:53] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 222300161 bytes) in [FILE_PATH]/wp-content/themes/lifegadget-pagelines/sections/lg_content/section.php on line 42
[25-Oct-2012 14:27:53] PHP Fatal error: Call to a member function get() on a non-object in [FILE_PATH]/wp-content/object-cache.php on line 52
So my questions are as follows:
Troubleshooting. Is there any way to troubleshoot memory usage?
Scale. Is exceeding a 256M limit a clear problem or is this justified in some cases?
New Ceiling. Why is my new ceiling of 512M being ignored? Not that I'm happy to have it stay at 512M but I would have thought it would at least get me back up and running (I have 16GB on the machine so there's plenty of physical memory).
Infinite loop can cause this or if you have circular references with pre 5.3 PHP version. See: Garbage collection
Inject this function ini_set('memory_limit', -1); at the very beginning of your suspected memory leaking class/page, this is a temporary solution to get things working but it won't help you know where exactly your script is leaking memory.
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 523800 bytes) in /Library/WebServer/Documents/XMLDataStore.class.php on line 981
The curious thing about this error is not the memory leak, which would be easy enough to troubleshoot. Rather, it is the fact that XMLDataStore.class.php is only 850 lines long, which I have verified in multiple text editors.
This is with the PHP 5.3 bundled with Snow Leopard. I'm not using an opcode cache. Here is my php.ini:
allow_url_fopen = Off
error_reporting = -1
display_errors = 1
display_startup_errors = 1
date.timezone = 'America/Los_Angeles'
output_buffering = Off
realpath_cache_size = 0k
XMLDataStore.class.php has recently been refactored and it used to be longer than 981 lines. It's almost as if PHP has cached a 2-week-old version and is reading that. I'm positive that the current version at /Library/WebServer/Documents/XMLDataStore.class.php is only 850 lines long, though.
Could this be a line break issue? i.e. the PHP interpreter breaking lines differently than your IDE / editor? I don't know about how PHP handles Linux/Mac/Windows linebreaks, but it might be a possibility.
Can you create a fatal error somewhere in the script, and look which line number it shows you?
Could there be some over-long lines in your code (> 65535 characters) that mix up the line counting?
Also what happens if you rename the file, and include it under a new name? THis should take care of any screwed up cache issues.
PHP Seems to have issues with macintosh style line ending, It doesnt count the cr at the end of comments. I had this issue after opening a file on a friends apple.
I used kate on linux and Crimson Editor on Windows to change the end of line back to Unix style and the line numbers worked fine.
If you are getting an error on a non-existant line then it may very well be that PHP is caching it.
Maybe try renaming it then executing it.
Not to sure about Snow Leopard, but I am using it right now and have to say there are a great deal of strange bugs with the OS alone, could be that.
I experienced this error before when I was accessing a DB and storing info in an array, turns out I forgot how large the DB was and when it passed MB on the stack I got that error and it stopped.
If the situation is similar use a more processor heavy approach, such as connect, get a line/ block/ whatever, to something, then go back.
Don't go through everything, store it all, then do something.
Check this out:
Drupal.org memory allocation error
Hope this helps, not sure how clear all of this is.
Maybe show parts of your script to get an idea of what might be causing this.
Here is some more info. I tried the same code on a different Mac running the same version of Snow Leopard - one that is rarely used for development and would not have a version of this file cached - same result.
Next I tried copying the same code to a Solaris box running PHP 5.2.8. I still get the memory error - which is fine and expected, of course, since it does exist - but the PHP error message says this instead:
Fatal error: Maximum function nesting level of '100' reached, aborting! in /export/www/htdocs/XMLDataStore.class.php on line 741
This makes perfect sense, as that is the first line of a method that is being called recursively by another method. Exact same code with same line breaks (LF) checked out at the same revision # from the same SVN repository on all 3 machines.
Bug in PHP 5.3.0 for Snow Leopard? :)
While I have no idea what may cause this wrong line counting (I'm using PHP 5.3 on OSX 10.6, too. No Problems here.), you can narrow down the actual error by dividing your script into smaller parts.
that way maybe you'll find the real location of your error.
And a 850 line PHP file could seriously use some refactoring anyway.
I was experiencing this issue as well recently, in my case (PHP 5.3 on Ubuntu/Nginix under php-fpm5) I had a script that was causing a 500 error with no output (due to it being on production). When examining the error log it mentioned line 589 on index.php which only had lines going up to 453. The solution in my case was support for the short tag was disabled on production but enabled for staging...
ie. <? was disabled and <?php was required for opening PHP tags.
The error in the log was obviously not helpful in my case so it took a while for me to troubleshoot it. I am leaving this suggestion here hoping it will save someone some time.