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?
Related
I'm a system administrator which handles a server that hosts an internal api created using Laravel 5. The data source is a SQL Server hosted on another server and the api is used in a IOS app for mobile phones. When the developers created the api, this error was not present and no other memory errors were found. When we went live this error has been popping up from time to time.
[2015-06-01 23:01:52] production.ERROR: exception 'Symfony\Component\Debug\Exception\FatalErrorException' with message 'Out of memory (allocated 262144) (tried to allocate 140189808036120 bytes)' in Unknown:0
I checked RAM, CPU, swap etc etc of the server but everything was ok. Not much of the resources are being consumed. I've checked PHP Memory limit from php.ini and is set to -1 which is the max according to PHP. I've checked it on CLI, phpinfo.php and httpd.conf I don't see anything wrong. The team tried following this link Allowed memory size of X bytes exhausted
This is a problem in the ios app because the app searches for a correct return code but when this error comes out, even if the ios app transaction is correct, it returns an error because the return code is incorrect as it is returning the code for the memory error.
The first thing I could think of was to restart the Apache httpd service. This immediately solved the issue. but I knew this is not a permanent fix for the issue. When I researched further, I got to know that the error comes when certain PHP scripts require more memory than PHP was allowed by default.
So the solution is to increase the memory allocated for PHP. How to do that? There are 4 possible ways –
Try looking for the php.ini file. You might find some redundant php.ini files, so make sure you have got the one which is actually being read by PHP. o be sure, create a new php file in your root folder, say “check.php” and have phpInfo(); within the php open and close tags. Execute this file to get the information on where the php.ini is residing. Normally it will be in /usr/local/lib/php.ini
Open the php.ini file in a text editor like TextPad (not in Notepad) and change the values for memory_limit. By default you should see memory_limit = 8M. Try changing it to 12M. If it doesn’t work, increase it to 16M or even 24M and so on.
In case you can’t find the php.ini file or do not have access to it, then open up the file which was throwing the error (admin.php in my case) and add a line below just after ini_set(’memory_limit’, ‘12M’);
You can even consider adding a line in .htaccess file which will resolve the issue.
php_value memory_limit 32M
Or else, Try adding this line to your php file:
Increasing memory allocated to PHP
ini_set(“memory_limit”,”16M“);
When saving a particular node, my Drupal 7 hits a WSOD and this shows up in the error logs:
PHP Fatal error: Allowed memory size of 633339904 bytes exhausted (tried to allocate 84 bytes) in /var/www/mysite.org/includes/form.inc on line 1780, referer: http://mysite.or/node/193/edit
Saving other nodes, it appears to be a problem with this node. How can I figure out what function is maxing out the memory? How do you even begin to debug something like this? It would be more helpful if Drupal logged an error in watchdog but there's nothing there either.
PHP as you will see, has a generous 600M of allowed memory (this is a large site with 16GB of RAM).
Any ideas?
You can, technically, catch the error in a shutdown function:
register_shutdown_function(function() {
var_dump(error_get_last());
});
But it won't be very useful seeing that you already have the type, file and line where the problem is occurring. In practice, you'll usually want to follow what's going on by inserting debug_backtrace(), var_dump() and die() statements where needed.
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();
}
}
});
I have a VPS apache server based in a farm.
Recently i sufferd from memory limit errors and i decided to increase the number of the memory limit by changing it in the WHM panel at PHP Configuration to 256MB. after i was presss the button "Save", i got my site (and other wordpress sites i have in my server) all over with random fatal errors and 500 internal server errors on my site: http://amadeus-trade.ru
I can log into the backoffice but, when i tried to go to System -> Configuration i get this error:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster#amadeus-trade.ru and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request
And when i try to add products i get this error:
Fatal error: Out of memory (allocated 19922944) (tried to allocate 1245184 bytes) in /home/amadeus/public_html/app/code/core/Zend/Date.php on line 2423
This error allways jumps from file to file and looks like this scheme:
Fatal error: Out of memory (allocated xxxxxxxx) (tried to allocate xxxxxxx bytes) in /home/amadeus/public_html/xxx/xxxx/xxx/xx/xx.php on line xxxx
Now, It is fresh installation. so far (until 01.11.12) the website worked great without problems.
The team in the hosting company says that this is aproblem of a code in magento but i positivly sure that the problem is on the server!
My WHM version was update by the team in 01.11.12 to v11.30
Can you assist me please how to solve this?
Looking at your error message
Fatal error: Out of memory (allocated 19922944) (tried to allocate 1245184 bytes)
in /home/amadeus/public_html/app/code/core/Zend/Date.php on line 2423
PHP is telling you it tried to allocate 1,245,184 bytes of memory, but that was over the limit allowed. It's also telling you there are currently 19,922,944 bytes allocated.
1,245,184 bytes is 1,216 kilobytes (KB), which is 1.1875 megabytes (MB).
19,922,944 bytes is 19,456 kilobytes (KB), which is about 19 megabytes (MB).
This means one of two things.
PHP thinks it's only allowed to allocate around 19 MB of memory
The operating system PHP is running on ran out of memory
Check your runtime php.ini settings to make sure your memory change stuck (use a single page calling the phpinfo function to do this). Also, make sure it's 256M, and not 256MB. The later won't be recognized by PHP, and "weird things" will happen (including a super low memory limit).
That said, my guess is it's the later. When my version of PHP goes over the limit set in the memory_limit ini, I get a slightly different error.
PHP Fatal error: Allowed memory size of 262144 bytes exhausted (tried to allocate 10493952 bytes)
PHP is telling me that it's allowed limit has been violated. Your error
Fatal error: Out of memory
Says PHP has literally used up all the memory avaiable to the server at that point in time.
Beyond that, you host's response show a lack of Magento specific knowledge — any host capable of running the system would be able to the give you the information I just did. I'd start by asking them what the maximum memory limit is for a single PHP request. I'd end by moving to a VPS host that advertising Magento capability and has a good reputation for it.
Could it be that 256M was lower than it originally was set to? As it sounds like you already know, Magento requires a minimum of (get this) 256mb of ram, and 512 is recommended, and certainly more for larger applications.
Run a phpinfo() command and see what the memory_limit property is set to. If you can, use your .htaccess to change the limit to a more reasonable level:
php_value memory_limit 512M
However, I must say that there is a good chance that your hosting provider will frown on changing this setting (if they don't allow you to do it in .htaccess).
I'm experiencing a strange situation.
My application logs lot of trace logs to a file. (I don't know exactly how, I use my frameworks logger. Can check this though)
Problems is, when an application is terminated by a fatal error (only fatal) [example - "Fatal error: Call to a member function someFunction() on a non-object"] , I end up with no logs, even logs that should have been recorded much earlier during the execution of my script.
(Yes, I tried to flush logs, this doesn't help either. It looks like the termination of the application by a fatal error, somehow cancels writing to files done at earlier points of the application.
Any ideas what goes on here?
Thank you
A Fatal Error is... well... Fatal : it stops the execution of the script, which will not do anything that should have been done.
In your case, I suppose your logging framework logs into memory -- and that this in-memory log is only written to the file when the processing of the request is done.
Some logging mecanisms do that, to avoid writing to a file several times, at different points during the generation of the response (which means keeping the file locked, to avoid concurrency problems ; or opening-closing-reopening-reclosing-... it)
As you get a Fatal Error, the normal operation that should be done at the end of the response's generation is not called -- and, so, the in-memory log is not written to the file.
Now, the only way to know for sure would be to take a look at the logging mecanisms of your Framework ;-)
Apparently, the fatality of the fatal error that Pascal mentioned, is not 100% fatal.
The below allowed me to have my logs even on fatal errors:
function correctShutdown()
{
logger->flush();
}
register_shutdown_function('correctShutdown');