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.
Related
I keep getting a mysterious error like this logged:
PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 134217736 bytes) in C:\BLABLABLA\unrelated.php on line 24
Of course, unrelated.php is not the script that does the actual function call. It's just one of the many files with wrapper functions in my framework.
My extended PHP error logger, which uses debug_backtrace() in order to be able to loop through and log the "full chain" of function calls leading up to the error. However, even that "smart" logger of mine falls short in this case:
Allowed memory size of 1,07 GB exhausted (tried to allocate 134,22 MB):
Row 310 # "C:\BLABLA\debug.php"
Row 1844 # "C:\BLABLA\irrelephpant.php"
Neither of those files is the origin script which is actually run, resulting in this error.
All of the files mentioned above are never run directly. They are just part of my framework, wrapping functions from PHP or each other.
I don't understand this. Everything about debug_backtrace() seems to suggest that it will find the "outermost"/base script, but it clearly doesn't in this case. I assume it's because a FATAL error...? What can I do to make it truly log the actual script that was run in CLI and ended up causing this error? (So that I can assign more RAM for it specifically.)
You can use the Xdebug profiler to see where the maximum memory is allocated. You can increase memory size by adding this line in your unrelated.php script at top ini_set('memory_limit', '512M'); or whatever memory size increase you need.
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 !
So, I know what the specific error I have is (Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 71 bytes) and what caused it.
I am not looking for the solution for that.
What I try to learn is how would I dump $_SESSION and $_REQUEST and stack trace into file when this type of errors happen, or if it is even possible.
This is not possible without additional modules--once you hit memory limit it's an immediate crash. However, You could install Xdebug module and have it log a stack trace like you indicate you want.
Here's some info on configuring the exact dump you want with xdebug: http://xdebug.org/docs/stack_trace
You can tell xdebug you want specific variables and super globals to be dumped. This should meet your needs.
Similarly, you could install Newrelic, but as with xdebug it's going to require a share module be loaded and you'll take a performance hit (and in this case it's not free).
I'm seeing this error in my production server, sometimes (I mean, it seems random, as my site as a decent traffic and so far it just happened 5 times):
[21-Feb-2012 23:43:19 UTC] PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 261900 bytes) in /home/xxxxx/xxxxx/xxx.php on line 1811
The funny part is, the file has only 798 lines, and this never happened before to me.
It may have to do with recent changes I made to my scripts, yes, but this error simply doesn't make sense to me.
Please keep in mind that I know what "Allowed memory size exhausted" error means, and I know how to increase the memory limit.
However, my question here is, why is PHP referring to a line that doesn't exist?
I don't know how to fix this problem, because this makes no sense to me.
Thank you.
I've just found what was causing this memory leak.
It was a recent change that was entering in recursion cycle between two functions, although it was a rare event.
The line 1811 is real, yes, but the file that the error was referring is not correct. The line 1811 was from another file (included on that referred one) where one of the functions is.
I still appreciate the help from the people who commented above.
When I login to my web application it shows an error like:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 87 bytes) in /gt/2.ps.fo/home/hft/domains/console.fo.spalgo.com/public_html/cake/libs/model/datasources/dbo/dbo_mysql.php on line 775
Is there any solution to solve this problem? Why do I get this error?
That sounds like you've allocated more memory than PHP will allow. Edit the memory_limit setting in your site php.ini configuration as described on the linked page.
Another possibility (less likely) is that you've hit the setrlimit(2) resource limits for your user or group. Check /etc/security/limits.conf for limits that might be set for your web server, along with whatever initialization scripts start your server environment and PHP interpreter environment.
The first example I found by searching SO for "PHP out of memory" is this one
Try using echo instead of storing what you are printing to a variable first.
Looking at the file that threw the fatal exception (dbo_mysql.php) I presume that your call is retrieving data from the DataBase.
Also, looking at the memory limit, it shows 134217728 bytes, which is 128MB, so I think that whatever your API call is doing, is trying to fetch a lot of data which total surpasses the limit allocated per script.
For example, if the last script in the API call stack were to use 20MB for its needs and then tires to fetch data from the DB worth 115MB, your script would be trying to allocate 135MB which is already 7MB more than the limit and thus causing the Fatal Exception.
So, I see a few things to check/do:
That you are not retrieving unnecessary data, or in other words, retrieve only what you need.
If you indeed need all that data, then
Either increase the memory_limit value under your php.ini file
Con: If your data keeps growing, you may need to keep updating this value for the only one script and exposing your self to memory leaks or running out of memory.
Or I would recommend that you implement some sort of pagination (which will allow you to keep memory limits in check) and make your application more scalable.
ini_set('memory_limit', '-1');