Recently my aplications started throwing errors of this kind:
PHP Fatal error: Cannot redeclare {X Class} (previously declared in {X File: X line}) in {X File: X line}
After some investigations, I came to the conclusion that the PHP code is somehow being executed twice.
To make sure, I created a file with the following code:
error_reporting(E_ALL);
define('SOMETHING', 'ITS OK');
echo SOMETHING;
die();
That is the entire code of the file. Yet sometimes, when requesting that file, the following error is beeing produced:
PHP Notice: Constant SOMETHING already defined in {Y File} on line 6
Do you know what kind of setting could be causing this?
The issue seems easyer to reproduce with fast consecutive requests but it might not be limited to that scenario, sometimes it seems to happen on a single request (but Im not considering this a fact)
The issue seem to appear because of proactive defense in imunify360. https://www.imunify360.com/proactive-defense . Disabling the proactive defense php module seems to resolve the issue.
Related
Please excuse an, at least initially, high level question about logging php script errors. Is it a valid expectation that php error_log will record errors in a class file that is in a different directory to the main php script?
I have two php files
pages/add_edit_xxxx.php
and
class/class_xxxx.php
add_edit_xxxx.php depends on public functions in the class file
If I deliberately introduce an error in pages/add_edit_xxxx.php then pages/error_log correctly records the line number of the error
If I deliberately introduce an error in class/class_xxxx.php then class/error_log sometimes records the error and sometimes remains unchanged
I do not have access to php.ini
But I guess that the settings are OK as sometimes class/error_log records the error but more often than not it does not log the error.
I have this in a settings file:
ini_set("include_path", '/home/xxxx/php:' . ini_get("include_path") );
error_reporting(E_ERROR);
#session_start();
Called at the start of pages/add_edit_xxxx.php
include_once("settings.php");
I hope this is enough to enable thoughts on whether it is a valid expectation that the errors in the class file should be reliably caught and logged. At the moment I cannot recreate a scenario when a log was created - but this is an example of class/error_log entry that was written yesterday
[20-Oct-2021 19:00:48 UTC] PHP Parse error: syntax error, unexpected '$tempRS' (T_VARIABLE) in /home/xxxxx/public_html/xxxxx.com/class/class_xxxx.php on line 36
If I remove the deliberately inserted errors (for example a missing semi-colon) then the page functions well.
Thank you
resolved by updating this line in the settings file:
error_reporting(E_ERROR);
to
error_reporting(E_ALL);
someone could tell me if there is a reason why I get these PHP errors, which should not exist.
PHP Warning: include (xyz.php): failed to open stream: No such file or directory in /mypath/myfile.php on line 351
When the file clearly exists!
PHP Fatal error: Can not access MyClass::$myproperty in /mypath/MyClass.php on line 250
When the declaration exists:
class MyClass
{
...
public static $myproperty = array();
...
I would like to emphasize that these errors are not always reported! But only once in a while. When I make a mistake writing a part of the code, the PHP fatal error should always occur, not 5 times a day from 12:22 to 12:27 and nevermore. I'm talking about a site from thousands of visits a day, I'm also talking about a .php file that is included on a regular basis in every request of any page.
I can't get any error in my pc (php 5.6 also) when I run and test the web application.
Is it possible some server problem?
Thanks.
I´m getting hundreds of these errors in the apache log in a website with around 4000 visits per hour. I have never seen any evidence of these errors affecting user experience in the website, but i believe it may be happening 1 in 100 requests or something like that, making it very difficult to diagnose.
These messages are really absurd as for what they say they should be killing the requests generating bad user experience, and DRUPAL_ROOT is defined in index.php, so how can it already be defined if it is called only once in the execution thread?
I've seen these errors are almost always close to a Core Dump error record. Any complete theories about what could be happening here?
And drupal_bootstrap not defined right after "require_once DRUPAL_ROOT . '/includes/bootstrap.inc';" how is this possible?
Have anyone seen this happen before?
These are the errors I see in the log:
PHP Notice: Constant DRUPAL_ROOT already defined in /var/www/vhosts/hsbnoticias/index.php on line 17, referer: http://diariodelsur.com.co/noticias/judicial
PHP Fatal error: Call to undefined function drupal_bootstrap() in /var/www/vhosts/hsbnoticias/index.php on line 20, referer: http://diariodelsur.com.co/noticias/judicial
I´m using a 6GB Linde Ubuntu LAMP Single Server, with around 300 to 400 apache preforked processes. The website seems to be working fine, so no errors are being reported by vistors, no evidence of errors in analytics, and haven´t seen these popping up in the client side my self.
Every now and then an image resizing script on our site will fail with the following error:
PHP Fatal error: Class '\xa0L\xdaor\x7f' not found ... on line 4
The actual line 4 of the script in question is:
$photo = new Photo($photo_id);
I have no idea where the hex code \xa0L\xdaor\x7f in the Error log comes from. The script will run fine and it runs relatively frequently for a day or two, then it starts failing every time, with that error.
If I run opcache_reset(), the errors stop.
Anyone have any idea what might be causing this issue?
UPDATE: I got no response - so I've simply excluded this file from the opcode cache using opcache.blacklist_filename.
Sometimes my whole PHP response was a bunch of hex codes like this.
I had that when opcache.fast_shutdown="1" was set.
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');