I got a strange bug going down here, sometimes select queries dies from a memory exception. The big problem here is that I've never been able to see the error by myself. I know its existence from users and the laravel.log file that contains things like :
[2015-03-05 11:46:07] production.ERROR: exception 'Symfony\Component\Debug\Exception\FatalErrorException' with message 'Allowed memory size of 134217728 bytes exhausted (tried to allocate 196605 bytes)' in [...]/vendor/laravel/framework/src/Illuminate/Database/Connection.php:301
Stack trace:
#0 [internal function]: Illuminate\Exception\Handler->handleShutdown()
#1 {main} [] []
My questions are :
How to debug the issue (find oud what is the query that blows everything up)
Or if there's a known workaround for this, what is it ?
I already tried to DB::disableQueryLog(); within my start/artisan.php
Main issue is:
The PHP process is running out of memory, aka hitting the memory_limit set in your php.ini. The cause may be various, i.e infinite loops, large select statements; so to say: anything that requires PHP to store information in memory during processing.
My specific Issue & Solution:
I had this issue due to long running php processes, i.e Queue workers.
Solved it by setting up a cron job that does a php artisan queue:restart every 20 mins.
As the error message said, the error was about a certain database query. But I also asked how I could traceback the faulty query. I used an error tracking service called Rollbar to find out which API call died. Pretty sure it isn't the best way to figure this out but it worked...
Related
I'm seeing quite a few timeout errors on a big laravel 5.1 site:
[2018-05-23 17:02:35] production.ERROR: exception 'Symfony\Component\Debug\Exception\FatalErrorException' with message 'Maximum execution time of 30 seconds exceeded' in /var/www/vhosts/{site}/httpdocs/bootstrap/cache/compiled.php:16501
Stack trace:
0 {main}
Looking into the compiled.php file on that line number leads me to: ExcludeDirectoryFilterIterator#hasChildren
This function is from symfony/finder (version v2.7.47)
https://github.com/symfony/finder/blob/34226a3aa279f1e356ad56181b91acfdc9a2525c/Iterator/ExcludeDirectoryFilterIterator.php#L73
I've used debug_backtrace on this function to see what's calling it and it looks to be laravel when loading the configuration from storage (local disk).
Does anybody know of any issue with this? Is the server disk getting hit hard at some times during the day causing loading the config to timeout?
Any help/suggestions much appreciated.
In the past week, I started to receive the following message in the Laravel log, but there is nothing else on my stacktrace to give me any clue of what is going on. Any idea of what this could happen?
[2017-11-30 19:40:05] production.ERROR: Maximum execution time of 0 seconds exceeded {"exception":"[object] (Symfony\\Component\\Debug\\Exception\\FatalErrorException(code: 1): Maximum execution time of 0 seconds exceeded at /var/www/html/app/vendor/laravel/framework/src/Illuminate/Support/Collection.php:1201)
[stacktrace]
#0 {main}
"}
I'm currently using Laravel 5.5 and PHP 7.1.
I managed to solve the issue. I checked Apache error logs, and it showed me the URL where the error was and from that point, I was able to review what happened. And it was bug in our implementation that was causing a weird iteration that took a lot of time. Now, it's solved.
I've faced very strange behavior of Laravel 5.3 on PHP7/Apache (Windows).
My application is working perfect for several hours, but in unpredictable moment site crashes with errors like:
- Symfony\Component\Debug\Exception\FatalThrowableError: Call to
undefined method DateTime::format() in
C:\site\telemed\bootstrap\cache\compiled.php:14049
- Symfony\Component\Debug\Exception\FatalThrowableError: Call to
undefined method Carbon\Carbon::modify() in
C:\site\telemed\vendor\nesbot\carbon\src\Carbon\Carbon.php:1806
- and so on...
Also found in Apache Error Log:
Cannot make non static method DateTime::b\x10Y7I\xc0\xf1\xbdff() static in class DateTime
It looks like PHP forgets about some part of system code... Carbon stops working even in Monolog.
After Apache restart things get normal. Or sometimes it can get normal without any actions after ~30mins.
Any ideas what is happening?
Thank you in advance!
UPDATE:
After composer update and php upgrade to latest 7.1 things get even more weird of 4 hours of normal work:
Symfony\Component\Debug\Exception\FatalErrorException: Allowed memory size of 838860800 bytes exhausted (tried to allocate 8083526415852724616 bytes) in C:\site\telemed\vendor\nesbot\carbon\src\Carbon\Carbon.php:1112 Stack trace: #0 {main}
Running Laravel 3.
I am trying to upload files with the laravel framework. If the file is larger than the php setting for upload_max_filesize it throws the exception below.
I have tried this in my controller and routes with no success (the if statement runs - it sets a session - but the exception is still thrown showing the error page)
if ($_SERVER['CONTENT_LENGTH'] > 8380000) {
//do stuff here because its too big
// set a session and exit()
}
How can I prevent this exception from being thrown without upping the php memory limits?
Error:
Unhandled Exception
Message:
POST Content-Length of 9306598 bytes exceeds the limit of 8388608 bytes
Location:
Unknown on line 0
As a side note, this question has been asked atleast twice in the laravel forum with no good answer given except for 'increase your php memory limits'.
EDIT: the problem seems to be that laravel is loading all the _POST inputs before I can even check them in the route or controllers. Seems like a bug to me.
This looks like PHP's max post size, which defaults to 8M on many systems (around 8388608 bytes). There is nothing you can do in Laravel to get around this as it is handled/managed/configured at the PHP level. Read Increasing the maximum post size to see how to change this.
PHP is raising this Warning and Laravel is threating it as a fatal error.
This is done in Error::shutdown, any PHP error thrown will result in an application shutdown due this error.
A solution I've found is to filter which error types are allowed to end in Error::shutdown.
The downside is:
Needs to modify a laravel file: laravel/laravel.php which is not a good idea if you plan to update laravel with new versions (something that will hardly happen now that version 4.1 out there).
Could not fully test if this implies some side effect in laravel behaviour by not aborting Warning errors.
This is the modification I made in file laravel/laravel.php line 46:
register_shutdown_function(function()
{
require_once path('sys').'error'.EXT;
$error = error_get_last();
if ( $error!==null )
{
if( $error['type']!=E_WARNING )
{
Error::shutdown();
}
}
});
On PHP 5.3.3-7, I'm using DOMDocument->load() to load a local file, and recently I've started encountering situations where I start getting E_WARNINGs
DOMDocument::load() [domdocument.load]: I/O warning : failed to load external entity "/path/to/local/file/that/does/exist"
Once this starts happening the only way I've found to make the errors stop is to restart apache, and then it's fine for a while again.
I haven't changed any related code recently, but it occurred to me that this started happening after I installed a Debian patch for CVE-2013-1643, which seems to possibly disable entity loading... if there's a single instance of an event that would trigger disabling, could that disable it permanently for all future PHP requests until a restart? That seems aggressive. By contrast, libxml_disable_entity_loader() seems to operate on the current request only.
I have no code that I know of that should ever load remote XML and that would ever trigger disabling, but if this is what's happening, I would have expected something to show up in my php error log, but I don't see anything. What other avenues should I investigate?
EDIT: Finally, I've been able to predictably repeat the problem. If I intentionally exceed the allowed memory limit in a single session...
mod_fcgid: stderr: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32 bytes)
...then I start getting the I/O warning on all subsequent calls to DOMDocument->load(). This time, I was able to get it working again without restarting apache... just by calling libxml_disable_entity_loader(false). This is truly funky behavior--it's starting to smell like a bug in php?