What could be the cause of these very unlikely high memory allocations attempts, I notice lately on my production server:
PHP Fatal error: Allowed memory size of 1006632960 bytes exhausted (tried to allocate 51002234388 bytes) in D:\wp\wp-includes\load.php on line 1466
This happened in Wordpress (see error message), but also in Lime Survey.
I'm running PHP 7.4.27 on Windows Apache 2.4.21 on a Windows Server 2008.
The error is consistent (same number of bytes, same script, same line) and remains after a server restart.
Strangely I could get rid of the error in a Lime Survey installation by simply moving all the script files to a different folder.
Edit: Same now: Downloading via FTP all the script files in D:\wp, creating a new directory D:\wp and uploading all the files fia FTP, the error vanished. What's going on here?
Thank you!
The cause is most likely plugin related.
I would check:
wordpress error logs
php error logs
Apache error logs
server error logs
any pending cron jobs.
isolate and debug any plugin DB queries.
are there any heavy reports (DB generated)
Isolating which plugin, can be done by using a live backup, and deleting/disabling plugins one at a time.
Increasing the memory limit may be done through wordpress, but may not bite, unless configured on the server or php level.
1 - check PHP 7.4 memory limit
(check php.ini -- check folder configuration
in the windows)
2 - Insert memory limit in wp-config.php
3- insert the memory limit in .htaccess
4 - Check the plugins.
5 - Possibly have a hidden malicious code file
( 5.1 - look for files with the same name as the folder. Example: FOLDER = theme (when entering the folder) there is a file with the name = .theme.php
5.2 - Analyze your index.php, wp-config.php or .htaccess (if they were not auterated, enter codes)
6 - Analyze the logs
Now, after a while I strongly guess it was the opcache functionality, that caused the error. Maybe after updating some of the scripts did conflict with left untouched ones in the opcache.
Turning off the opcache did the trick (till now :)).
Related
When I try to install Opencart V3.0.2.0 in Linux server, getting following error message.
Fatal error: Internal Zend error - Missing class information for in
/system/storage/vendor/twig/twig/lib/Twig/ParserInterface.php on line
31
I am not able to start my installation process. Any idea, Please help.
While this is not guaranteed to work, but since few people reported that they have been able to solve it disabling APC I would give it a try.
If you want to disable Alternative PHP Cache (APC), you can do so by modifying your PHP initialization file file.
Using your hosting account's editor (Web & Classic / cPanel / Plesk), open your website's PHP initialization file.
Note: I recommend backing up your PHP initialization file file before modifying it. You can do this by copying and renaming it in your file manager.
On a new line, type apc.enabled=0
Save your changes.
We're using Yii framework for an internal tool.
What we have now :
The user select a file .txt to upload on the server.
The server clean the text file because it containts lots of characters such as """ and ;;;;
But when comes the time to import to database, server sends a 500 internal error with no more information.
The file size is 8.1 mo. The import seems to work if we delete manually some rows in order to make the file at less than 7 mo.
We took a look at the php.ini file and increased all the limits.
What is weird is that we made local server with easyphp (same config in php.ini) and it works.
Do you have an idea ??
Thanks !
With the information's you have provided, I can only suggest that turn on error_reporting and display_errors in your php.ini file.
Increase maximum execution time and then see if any error displays or not?
Also do you have access to your log files in server? Then check php error_log for more information.
Do you have some error logging (preferably written on the server, as the 500 pages generally not show the error).
Many servers are configured to return a 500 internal error in case of an error in a mysql_query. So either there is omewhere in the 8MB in issue (which does not appear to be the case, if it works in exactly the same table on another server), or the query is too long (increasing the limits is not always possible on a shared server).
If you share some code and/or error message that may help to find the issue.
There is also a limit on the SQL server, defined by max_allowed_packet. Please take a look on the result of
show variables like 'max_allowed_packet';
Maybe this is set to low.
The websites on one of my Plesk users can't be accessed. The server reports a 500 Internal server error, the error_log for that user shows a bunch of
[warn] mod_fcgid: read data timeout in 60 seconds
[error] Premature end of script headers: index.php
The DocumentRoot contains a normal WordPress installation. Other sites running the same WP version, using the same DB server and PHP+Extensions run fine. A <?php phpinfo(); ?> runs fine as well. Calling php index.php from cli returns the webpage, but is a bit too slow for an idle Xeon E5-2620 Server w/ 64GB RAM
Are there any known Problems? How can I debug further?
Some more system info:
PHP 5.6.24 (tried 5.4 as well)
Plesk 12.5.30
EDIT: The Problem occurs intermittently. Right now, no 500 Error is returned, site loads fine (a bit slow). I increased memory_limit, just to be sure it isn't a config limitation
You can try to increase FcgidIOTimeout as described here https://kb.plesk.com/en/121251
Since Plesk 11.5, "FcgidIOTimeout" parameter is set to the same value as max_execution_time php parameter in domain's PHP settings
Also you can try any of PHP-FPM handler instead of FastCGI, because of mod_fcgid has a lot of internal performance limitations which can't be avoided.
The problem was caused by a rogue file_get_contents in some scripts.
I looked through the error log for the 1st appearance of the error message, and found a file created exactly when the error message first appeared - only 2 years earlier...
WordPress Site hacked? Suspicious PHP file
So I removed the malware ( detailed write-up at https://talk.plesk.com/threads/debugging-premature-end-of-script-headers.338956/ ), rebooted the Server and the error is now gone.
Technical detail: The error turned up because the Server distributing the malware is offline. file_get_contents("http..." timed out, the local script failed and returned the error message.
I've got a major issue with PHPMyAdmin since a recent update. If I try to access any PHP files in the phpmyadmin (/usr/share/phpmyadmin) directory I get a 500 error. This even happens if I simply create a
<?php
phpinfo();
?>
file to display current PHP info in the same directory.
I don't have this issue in other directories on my server. MySQL is working fine, and I can create and modify tables manually. WordPress sites on my server relying on MySQL work fine.
I did notice I was getting
Allowed memory size of 262144 bytes exhausted (tried to allocate 7040 bytes) in /usr/share/phpmyadmin/index.php on line 141
However, this doesn't happen constantly and the 500 error happens regardless. I've checked the php.ini files for all types (CGI, CLI, apache2) and all have a 256MB memory limit which seems ample. I tried increasing it to 512MB and restarting apache2 but to no avail.
This only seems to have happened since a recent update about 2 months ago.
Any ideas what might be causing this? Other software on my server such as roundcube webmail, WordPress and others work absolutely fine and do not present errors.
Thanks in advance for any help.
UPDATE As a workaround I've installed a seperate copy of PHPMyAdmin in a different area (without touching the Debian installed version). This works fine so I'm cosidering it a workaround for now. There must be some sort of PHP configuration issue that is denying access to the directory or not allocating any memory at all for one reason or another. Solution not yet determined.
I'm posting because after hours of searching I'm utterly confounded. Here's the deal. My Laravel application uses the PHP Image Workshop bundle. Everything seems to be working fine, except if I try to make a resizeInPixel() call or a cropInPixel() call (or similar calls) the server throws an internal server error. If I investigate the error log I see:
Premature end of script headers: index.php
This only occurs when I use the resize and crop related methods (i.e. image processing). I can initFromPath() with no issue, and I can use the save() method without issue. Only the image processing methods cause the internal server error.
I've also read online that this can be the result of a suphp_log file exceeding 2GB. I've tracked down and cleaned out that file, but to no avail.
Any thoughts are most welcome! Even if they're just general "have you tried...".
UPDATE
I've narrowed it down to a particular line in the Image Workshop code. This line is causing the error:
imagefill($image, 0, 0, $color);
Additionally, this error only occurs when the color is created using imagecolorallocatealpha, NOT when it is created using only imagecolorallocate.
There are some great hints for solving this issue at Liquidweb.com. My money is on #2 (see bold text) because you are getting the error when doing image manipulations:
Sometimes when executing a script you will see an error similar to the following:
Premature end of script headers: /home/directory/public_html/index.php
This error occurs because the server is expecting a complete set of HTTP headers (one or more followed by a blank line), and it doesn’t get them. This can be caused by several things:
Upgrading or downgrading to a different version of PHP can leave residual options in the httpd.conf. Check the current version of PHP using php -v on the command line and search for any lines mentioning another version in the httpd.conf. If you find them, comment them out, distill the httpd.conf and restart apache.
The RLimitCPU and RLimitMEM directives in the httpd.conf may also be responsible for the error if a script was killed due to a resource limit.
A configuration problem in suEXEC, mod_perl, or another third party module can often interfere with the execution of scripts and cause the error. If these are the cause, additional information relating to specifics will be found in the apache error_log.
If suphp’s log reaches 2GB in size or larger you may see the premature end of scripts headers error. See what the log contains and either gzip it or null it. Restart apache and then deal with any issues that the suphp log brought to light. The suphp log is located at: /usr/local/apache/logs/suphp_log
The script’s permissions may also cause this error. CGI scripts can only access resources allowed for the User and Group specified in the httpd.conf. In this case, the error may simply be pointing out that an unauthorized user is attempting to access a script.
UPDATE:
After some more info in the comments, I still feel this is a memory related thing.
According to this SO wiki: About gdlib
Warning: Image functions are very memory intensive. Be sure to set memory_limit high enough
What is your PHP memory_limit? Can you crank it up a bit?