I have no idea how to go about solving this very occasional funny state that PHP gets into. So any ideas whatsoever will be appreciated.
Maybe 3 or 4 times in the past year, my site will start returning 500 errors, and the logs show:
PHP Fatal error: Couldn't execute method dw__autoload in Unknown on line 0
dw__autoload is registered with spl_autoload_register. When I restart apache the problem is gone and I forget about it for several months. I am running APC, php 5.3.2-1ubuntu4.10 on ubuntu 10.04.3. I realize there is not much to go on here!
Following the source code from the point of this error, I'd risk (psychic debugging since you have no more details) to say this happens because the autoload is being called with already an exception thrown.
That said, I can't see exactly how this can happen. The current exception is cleared both before calling the autoloader and after calling each SPL autoloader function. I don't think we ever can get to a conclusion without a script that reproduces this problem. The full set of possibilities is:
The execution was already shut down
There's a current exception
The function is no longer valid (I see that happening only due to a bug in PHP, but anyway it's not likely because it almost certainly would generate a warning before)
The autoloader function requires a reference (again, this would also generate a warning before, and your autoloader would never work anyway)
Related
I'm trying to understand in the Breaking Changes for PHP 7.4 to 8.0 what is causing the below line to throw a Fatal TypeError. Obviously, I know it isn't correct but need clarity on what is causing it. Perhaps it has something to do with the php.ini default value changes? I don't get any errors using PHP 7.4.
echo method_exists(false, 'pre_setup') . PHP_EOL;
I'm not sure why it isn't listed anywhere in the breaking changes (unless I'm missing something). It certainly seems like one.
The change was Bug #79462 being fixed, which aligned the behaviour of method_exists and property_exists. The decision was to go with the stricter of the two behaviours, and raise a TypeError on invalid arguments.
It's listed in the PHP 8 changelog, although I can see why that would be hard to track down.
One of the Symfony core team opened a PHP bug for it here: https://bugs.php.net/bug.php?id=79623, so you're definitely not the only person that's been affected.
A PHP software I wrote has been working fine for years suddenly throws this error: i360: Error in global initialization
This error is being thrown from the callback function register_shutdown_function('my_shutdown');
The callback function is just something this:
function my_shutdown ()
{
chdir(getcwd());
$e = error_get_last();
if ($e)
trigger_error($e['message'].' on '.$e['file'].' ('.$e['line'].')', E_USER_ERROR);
}
The full error message that trigger_error throws is:
i360: Error in global initialization 1 on Unknown (0).
It doesn't give much clue. Any ideas what could be causing it?
Update 1:
If I comment out the entire my_shutdown() function, the script works fine but I am still intrigue as to why this error happened just today after years of working fine.
Update 2:
Tentative info: this appears to be related to Imunify360, a security software for web servers (which my host uses that I'm not aware of or have control over). Investigation ongoing.
This issue is caused by Imunify360 because of a recent update to include a feature called "Proactive Defense":
https://www.imunify360.com/blog/meet-imunify360-with-proactive-defense-the-sophisticated-protection-against-any-kind-of-malware-all-in-one-nice-package
To fix this you need to have your host disable the extension over all PHP versions:
sed -i "s/extension=i360.so/;extension=i360.so/g" /opt/alt/php*/etc/php.ini
That should fix the problem for the time being.
This error happened just today. It disappears when I delete my cron jobs on Hawk Host cpanel.
This error was confirmed to be coming from Imunify360 (a security software for web servers). At the time of this writing, the issue was already fixed on their end. I presume an update was applied to servers using it so if you're still getting this error, contact your host.
When I attempt to access my magento site or admin panel I receive this error:
Fatal error: require_once() [function.require]: Failed opening required '__DIR__/composer/autoload_real.php' (include_path='/homepages/1/d372694303/htdocs/Magento 1.8/app/code/local:/homepages/1/d372694303/htdocs/Magento 1.8/app/code/community:/homepages/1/d372694303/htdocs/Magento 1.8/app/code/core:/homepages/1/d372694303/htdocs/Magento 1.8/lib:.:/usr/lib/php5') in /homepages/1/d372694303/htdocs/Magento 1.8/app/code/local/Elite/vendor/autoload.php on line 5
All I did was disable all caching from the admin panel and now I cannot access the site. Is there a way to re-enable caching? I attempted to re-enable caching via phpmyadmin with the sql command
UPDATE `core_cache_option` SET value=1;
This did not solve my problem.
This looks like an error specific to your system. Either custom development, weird stuff done m third party extensions, or both.
PHP provides you with all the information you need to debug your error.
If you parse apart your error message, first there's the error
Fatal error: require_once() [function.require]: Failed opening required 'DIR/composer/autoload_real.php'
As others have pointed out, the magic constant __DIR__ is being included literally in a string.
Second, in parenthesis, PHP lets you know the include paths during the request
(include_path='
/homepages/1/d372694303/htdocs/Magento 1.8/app/code/local:
/homepages/1/d372694303/htdocs/Magento 1.8/app/code/community:
/homepages/1/d372694303/htdocs/Magento 1.8/app/code/core:
/homepages/1/d372694303/htdocs/Magento 1.8/lib:.:
/usr/lib/php5')
These look pretty standard (although personally I wouldn't include a space in your "Magento 1.8" path name, but I'm old)
Third, and finally, PHP tells you where the error happened.
in /homepages/1/d372694303/htdocs/Magento 1.8/app/code/local/Elite/vendor/autoload.php on line 5
So line 5 of app/code/local/Elite/vendor/autoload.php is where the error occurred.
As to why it occurred, it looks like someone is trying to use composer to install something in the Elite folder. This could be how the extension/theme provided in Elite shipped, or it could be something another developer has done to the system.
When you disable to cache in Magento, the things Magento would normally pull from cache need to be regenerated. That means more, and different, code runs. Turning cache back on won't fix this, and Magento first needs to cache something before it can pull it from cache. My best guess as to what happened is a developer was working on something in the app/code/local/Elite folder, something that normally isn't called when the system is cached.
There is an error in your SQL syntax, try the following.
UPDATE `core_cache_option` SET value=1;
Should be
UPDATE `core_cache_option` SET `value`='1';
The code:
<?php
class My_Test{
public $exists = 'yah';
public function test(){
return $this->exists;
}
}
$test = new My_Test;
echo $test->test();
produces the following error intermittently (every other page request on average) on two servers:
( ! ) Notice: Trying to get property of non-object in test.php on line 8
Call Stack
# Time Memory Function Location
1 0.0003 636392 {main}( ) ../test.php:0
2 0.0003 636840 My_Test->test( ) ../test.php:14
where line 10 is `return $this->exists;
Please note this is not an untested example, it is the full code that produces the error. I'm aware the code is valid but it doesn't work in two environments.
I'm really not sure why! One server is running PHP 5.3.3 (fedora), the other PHP 5.3.2 (ubuntu). I've tried rebooting the servers too. They don't share anything, although they are on the same network.
Anyone got any tips for debugging?
There's nothing wrong with your test code. It runs without issue on PHP 5.3.3. You've probably lost the cause of the issue when converting your "real" code into test code to post on here.
As people before stated the code looks fine and should not cause any errors.
Therefore I guess it is related to an error of the php engine itself:
How did you install PHP?
Did you compile the sourcecode yourself? Have ./configure or make logged any warnings or error messages while executing?
Have you installed PHP by use of a package manager? (I guess everything should be fine then).
How did you configure PHP?
Have you made any changes to php.ini like changing memory limit, paths, etc. ?
Have you installed any extension that might cause issues? My experience says often opcode caches (e.g. APC) can cause errors that cannot be easily explained. Also debuggers or other extensions may cause interferences.
Do you have any (additional) error messages in your HTTP-Daemon-Log?
Sometimes additional errors can be found in the error.log file in case the server is configured to do so (e.g. unexpected termination of script or similar).
The code appears to work as is, but I've never seen an object instantiated without the parens.
$test = new My_Test;
// Should be
$test = new My_Test();
You could also implement some logging:
public function test()
{
// Can edit this to use instanceof or getclass for further testing
if (!is_object($this)) {
error_log(serialize($this));
}
return $this->exists;
}
I'm working on a large (inherited) codebase in PHP, and the error Exception thrown without a stack frame in Unknown on line 0 has started showing up at the bottom of every page. I understand what the error means: an exception is getting thrown someplace it can't be thrown. I've even managed to track it down somewhat—it's happening during the time shutdown functions are being called.
I've put logging in all the functions which get registered with register_shutdown_function, and it's not happening in any of those. Unfortunately, I can't seem to get any more information than that; I know what the last shutdown function to get called successfully is, but I have no idea what code gets executed between that and the point where the error happens. I don't even know what part of the PHP machinery is calling that last shutdown function. It might be something with the logging framework, or the session framework, or anything of a half-dozen things.
Does anyone know how to pinpoint where the error is occurring?
This can happen in destructors and exception handlers which don't have a stack frame. But since the message is so very helpful, your only option is to try to use echo to find the bug (and maybe ob_end_flush()). It may be that a destructor is throwing an exception, or is calling a function that throws an exception. Once you've located the buggy function, add a try...catch around the exception throwing part.
Note that if your framework uses its own error handling, you have to turn off warnings and notices in the PHP configuration. Especially if you have something like ErrorException, since it turns warnings into exceptions.
This message appears when an exception in thrown within your exception handler or your error handler (and maybe also in shutdown functions)
You should look for theses methods see if nothing strange appens in here.
Just found your question after experiencing the same error in a web application deployed to a Ubuntu 11.04 server, running PHP 5.3.5. I agree to #Eisberg that this issue seems to be an issue with the PHP 5.3-version exclusively, as the error haven't been present with previous, other PHP versions on other environments, where my application have been deployed to.
As #jmz mentions, I have also utilized an error handler that turns errors into exceptions for easier debugging at my staging servers.
To figure out what caused this mysterious behaviour, I debugged the application using XDEBUG & my IDE (Eclipse) and found out that one of my libraries tried to access & modify the global$_SESSION variable, when no session-data were set. Wrapping my code in an if-statement checking isset($_SESSION) made the issue disappear.
Why the exception didn't bubble up completely all the way to the browser, as other errors have done when trying to access non-set variables, is a complete mystery for me, especially as I got below error settings set, but maybe altering the setting in error_reporting() would have made a difference.
Error handling settings, for reference:
error_reporting(E_ALL | E_STRICT);
ini_set("display_errors", 1);
ini_set("html_errors", 1);
I get the same error msg too. MySQL database quota was set by awardspace as 50mb. Using PHPmyAdmin to optimise files showed a size of 34 mb but at cPanel the size was shown as 57mb. Every time when I visit my website and this error msg occurred, all I need to do was to login into awardspace, choose database, management, and reset file permissions. Then the error msg goes away, and my website is back up.
I was getting this issue in PHPUnit. I have added below code in function tearDown and helps me to get the actual error. You should wrap destructor inside a try-catch block, as the stack-frame only gets lost as soon as the exception is getting outside the destructor. Might be this can help someone else too. Source
function __destruct()
{
try
{
/*
your code
*/
}
catch(Exception $e)
{
echo $e->__toString();
}
}