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.
Related
When running the following command once:
<?php
$imap_structure = imap_fetchstructure($mail_connection, $email_number);
?>
I get the following error message:
Unknown: [UNAVAILABLE] FETCH Server error while fetching messages (errflg=2)
To confirm that PHP's imap_fetchstructure function was causing the error I used die(); after each imap_* function from the top of the function moving down until I started receiving the error again. Here is a list of things I've checked:
Each email message is successfully retrieved from Yahoo and added to the database as if nothing went wrong; the process is dependent on getting the structure of this email so on that alone I'm at a loss as to how something can work while also throwing an error.
This literally just started happening randomly after having already tested my mail script on a few hundred emails (not all at once, in much smaller batches).
Only happens with PHP's imap_fetchstructure function; when looped (e.g. for ten emails) the error will occur for each iteration.
Only occurring for the Yahoo mail server, other servers aren't triggering this error with the exact same code.
The custom error handler fails to return the line number (though I know where the error is occurring.
I tried suppressing the error by using #imap_fetchstructure() though the error was still being reported.
I tried sticking the code in to a try {} / catch (exception $e) {} though, again, the error was still being reported.
I restarted my server and pulled a different IP just because that has worked in stupider situations though no dice.
[Edit] The issue stopped little less than an hour after it started.
I've come across a few folks who have reported such as at Mozillazine:
I have recently started getting this "[UNAVAILABLE] UID FETCH Server error while fetching messages" too with my Yahoo account.
Their next post:
So today, without doing anything differently, the problem solved itself. That seems to say it was on Yahoo's end but it's still odd that while it was happening in Thunderbird it wasn't happening in other email clients.
Beyond literally hard-coding my custom error handler to ignore this error how do I suppress or code my system to better handle this situation?
Had a similar issue (not with programming) with Yahoo (in Thunderbird) and found this answer. Don't know if it would apply to your situation:
You can try to reduce the "Maximum number of connections to cache" for any of the affected Yahoo account(s). The option is in Account Settings -Server Settings - Advanced.
Mine is set to a value of 3 (was 5), which works for Yahoo.
I am using a library which connects to a remote service. The library will generate a PHP Fatal error / Uncaught ErrorException in case the connection terminates unexpectedly.
My PHP script is running as a daemon (via Systemd), so I would like to automatically restart the daemon after a while to reconnect. All this is setup in Systemd, so if PHP exits with the status 4, the daemon will be restarted after some time.
PHP uses the exit code 255 by default for fatal errors, so I resolved to using a shutdown function similar to the following:
function shutdown() {
// Do a bit of this and that (e.g. assert
// there actually was the relevant error)
exit(4);
}
register_shutdown_function('shutdown');
trigger_error('Test', E_USER_ERROR);
But whatever I try, I cannot influence the exit code in any way. I have not found anything helpful in the documentation.
Is there any known way to manipulate the exit code within a shutdown function or by other means after the fatal error has already been generated?
This is a bug in PHP, which apparently has been filed multiple times over the years:
https://bugs.php.net/bug.php?id=65275
https://bugs.php.net/bug.php?id=62725
https://bugs.php.net/bug.php?id=62294
https://bugs.php.net/bug.php?id=23509
It is supposed to be fixed already, but as of PHP 5.5.30, I am still experiencing it myself.
I suppose you could try reverting to PHP 5.3, which was reportedly working as expected. Or you could check out one of the most recent releases (5.6.18 or 7.0.3 as of this answer), to see if the bug is indeed fixed.
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 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)
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();
}
}