Trying to use the Simple HTML Dom Parser in my application.
Placed the sample function of scraping_slashdot() into a controller.
include_once('includes/simple_html_dom.php');
$ret = $this->scraping_slashdot();
print_r($ret);
Get:
ErrorException [ Fatal Error ]: Allowed memory size of 134217728 bytes exhausted (tried to allocate 291337 bytes)
The thing is that when I do the exact same thing in a stand-alone file (not as a part of a Ko app), everything seems to work just fine.
Does anyone have any idea what it could be?
PS
Using Ko 3.2, haven't tried other versions, though I've used this class in 3.0 before just fine.
Your script is trying to allocate more memory then allowed. Try using a profiler (Xdebug) to see where does the leak come from or use workaround solution - ini_set('memory_limit', '-1') or set it directly in php.ini if you have access.
Related
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've been working for hours on this issue and I'm about to get mad ! I develop a Symfony 3 application for more than a year, without any big problem. I was implementing some DoctrineEventListeners to my User Entity, everything was fine. But I now have an Error 500 for each page I want to access to (even the ones where there is NO call to these EventListeners). And my php log says this :
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32768 bytes) in /Applications/MAMP/htdocs/symfonyjf/var/cache/dev/ContainerXu4ttxs/getDoctrine_Orm_DefaultEntityManagerService.php on line 41
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32768 bytes) in /Applications/MAMP/htdocs/symfonyjf/vendor/symfony/debug/Exception/OutOfMemoryException.php on line 1
I reversed all my last changes, so there is no "new" EventListener in my project. But still, the project still shows a blank page.
Do you have any clue to help me ?
Thanks a lot !
At first you have to clear your cache so you are sure that you are running the correct version of code. Secondly I suggest to use the Symfony Stopwatch Component in order to monitor the memory usage of different code blocks in your project in order to understand where you have the largest memory consumption. Finally, if you can (i.e. you are not using a shared hosting environment) increase PHP allowed memory in your php.ini file.
I finally checked service by service and I found the one that was causing what I guess was an infinite loop. It was an Injection of EntityManager inside a service triggered by a Doctrine EventListener, which is (I guess) not allowed.
Thanks everybody !
I am debugging a Joomla website. For learning purpose, I just want to see which file calls/requests a module's modulename.php file, so I put print_r(debug_backtrace()) in the top line of the modulename.php file, but an error triggered saying:
Allowed memory size of 134217728 bytes exhausted (tried to allocate
98570240 bytes)
I am stuck here. Can someone give me an brief explanation why debug_backtrace() fails in this circumstances?
Use flag DEBUG_BACKTRACE_IGNORE_ARGS, e.g. print_r(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS));
If you want to display pretty stacktrace with parameters passed to functions, I recommend use my library error-dumper, see an example how it works.
Hello i am facing the problem of Allowed memory size error. I have created the project in codeigniter, php and I have used Tbs library. Its worked fine but today it display the error:
Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 258010 bytes) in
/home/abc/public_html/application/libraries/Tbs.php on line
4222
Please give me any suggestions.
If you are using TBS + OpenTBS in order to merge an XLSX file , then there is a known problem fixed with OpenTBS version 1.9.2 : if the number of row to merge is quite numerous, then you can have a very long process or a memory size error when calling $TBS->Show().
Use OpenTBS 1.9.2 or higher which is optimized for this point, and if the process is still long you can optimize more using the OPENTBS_RELATIVE_CELLS command.
"Allowed memory size of XXXXXX bytes exhausted" is a typical error when you don't have, as it's own name says, enough memory available for the php query to run.
Try upgrading memory_limit variable on your php.ini file, or by setting up ini_set('memory_limit', 'XXXM'); on your PHP file that you are running, being XXX the amount of Mb memory that you want to define.
If this isn't the case, you might have a bug in your software that is causing, i.e. a loop that is consuming memory without any control; but as you have said that it did work before...
Anyway, please check all the other answers from StackOverflow on this aspect:
Fatal Error: Allowed Memory Size of 134217728 Bytes Exhausted (CodeIgniter + XML-RPC)
CodeIgniter Fatal error: Allowed memory size of bytes exhausted
Codeigniter - Allowed memory size exhausted while uploading
Generally this type of occurs when your script is using too much memory. This can often happen in PHP if you have a loop that has run out of control and you are creating objects or adding to arrays on each pass of the loop. Check for infinite loops.
If that isn't the problem, try and help out PHP by destroying objects that you are finished with by setting them to null eg. $OldVar = null;.
Check the code where the error actually happens as well. Would you expect that line to be allocating a massive amount of memory? If not, try and figure out what has gone wrong.
Never upgrad memory_limit variable on your php.ini file, or by setting up ini_set('memory_limit', 'XXXM'); on your PHP file that you are running, being XXX the amount of Mb memory that you want to define.Letting application to eat memory he wants to is insane step.Try to find out bug does your application wants that much memory?? Find out
I ran into this rather annoying issue the other day; when a page tries to load it will just 'stop' half way through returning half a page to the end user. The exact error is shown below.
[03-Jul-2015 03:15:04 Europe/London] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 18996 bytes) in [path]/concrete/vendor/imagine/imagine/lib/Imagine/Gd/Image.php on line 602
I spoke to my host and they bumped up PHP's memory to 512M (which is a bit overkill) yet it still throws this error. I'm not sure if it's a memory leak in Concrete5 somewhere or if it is just the server that the site is hosted on.
Any suggestions are much appreciated.
Edit: Forgot to mention I'm running 1.7.4.2
Edit 2: For reference the exact function is imagecreatetruecolor()
Either:
ini_set('memory_limit','256M');
Inside PHP or getting your host to bump up the memory limit will do the trick.