During the development, I opened website logs and found a large number of errors with the same text:
local.ERROR: Cannot redeclare fun() (previously declared in C:\laragon\www\am\bootstrap\helpers.php:10) {"exception":"[object] (Symfony\\Component\\ErrorHandler\\Error\\FatalError(code: 0): Cannot redeclare errorText() (previously declared in C:\\laragon\\www\\am\\bootstrap\\helpers.php:10) at C:\\laragon\\www\\am\\app\\helpers.php:10)
At first I thought that these errors occur in parallel with my action on local website, but it turned out that these errors appear every 1 minute in the logs. I do not understand what provokes them. There are no such errors in the browser during operation, even if the website without action for several hours, logs still fill every minute.
I learned everything I could about the help file. The only option is to check if the function exists, but this is not the best practice, especially since the site works and does not give any errors in the process.
Fucntion check example:
if (! function_exists('fun')) {
function fun($field) {
return view('static.error', ['field' => $field]);
}
}
But rewriting and wrapping dozens of functions is not a good idea. Moreover, the problem remains and it is still not clear to me where and how these errors appear, what provokes them? Additionally considering that I have a static php website.
I will try to explain everything in the simplest possible language. A long search for an answer led me to the obvious thing. The whole problem is solved by creating a file inside bootstrap laravel directory. I trusted the opinion of the weighty answers here, but they are no longer relevant for today's queries.
It is also very important not to leave helpers.php inside app directory, even if it is not connected anywhere. This is what caused constant log entries.
All this will avoid duplication errors of any type and and will be compliant.
Related
I am seeing some very strange behavior today and I do not know what to make of it. We've been using codeigniter on our site for more than a year now and today when I clicked on one of our pages I saw a database error shown to me. I quickly opened up the controller for that page and refreshed to see it again but it did not happen this time, and I couldn't get it to trigger there again.
Hmm, alarming.
I navigated to a few other pages and it happened again on another, this time I looked at where it failed and it died on a query like this:
SELECT `foo`.`ID_NO` JOIN `bar` ON `bar`.`foo_ID` = `foo`.`ID_NO` WHERE `someSetting` = 0 AND `bar`.`Filter_ID` = '123'
...wait a second, where's the 'FROM foo' that should be in there?
I looked at my models controller and the following lines of code are what it tried to execute:
$this->db->select("foo.ID_NO");
$this->db->from('foo');
$this->db->join('bar','bar.foo_ID = foo.ID_NO');
This is code that has worked for a year and an error like this, anywhere, has not occurred before. It very much appears as though "$this->db->from('foo');" simply didn't happen.
I navigated to a bunch of other pages on the site and it happened a few times more, again same problem where the query wasn't being built correctly and a database error was thrown. When refreshed the error always went away. I haven't seen a repeat on any pages, nor have I seen a page pass then fail at a later time.
There are two things that maybe could be a factor: First, I recently added an error/exception handler (But that shouldn't have an impact on this, especially not once and then not again as far as I can tell).
Second, when I started using the error/handler I found an error in CodeIgniters that was known and was fixed by changing "function is_loaded($class = '')" to "function &is_loaded($class = '')" in Common.php because of an error that happened in Loader.php: "$this->_base_classes =& is_loaded();". That fix seemed to be widely accepted, and the error I'm experiencing is not repeatable and doesn't seems related so I also don't believe that is the cause.
I am using CodeIgniter version 2.1.2. Has anyone seen anything like this before? I can't imagine what the cause of this is but I would hate for it to happen outside the dev environment where I saw it happen today.
EDIT: Also, my fancy new error logging system I mentioned did not log anything that went wrong in the db->from function :(
The cause was my error catcher getting triggered due to referencing an index that didn't exist:
if($post_array['query'] != ""){
The error logger then gathered it's info and inserted into the database. I guess that it uses the same $this->db->ar_from field when you insert this way:
$this->db->insert('error_logging', $data);
Then clears it out afterwards as it does after any successful query.
The code then returned to it's previous position, with it's ar_select, ar_like, etc. fields intact but not ar_from and moved onto the $this->db->get() command which failed.
On subsequent page loads the error was already logged in the db and so a new insert was not performed and the query builder was not tampered with, and so no new database errors.
The fix was to simply get a clone of $this->db and use that clone to perform the insert.
[Update 18.01.14]
This question was marked a duplicate of Intermittent PHP Abstract Class Error . However, they are different in much of the bug appearance as follows.
That link only have contains x abstract method error. But mine have more types, and the errors are more weird (see the errors below, even containing some control characters).
In that link, the questioner said disabling opcache will make it happen less frequently. But in my case I did never enable the opcache but these bugs happened.
[/Update]
I am using Apache, PHP, Laravel to develop my web backend. But several times a day, errors will occur saying some php built-in functions are undefined, but at other time when it is not mad, these functions are obviously defined and work well. (So it is not because I call something really undefined!)
There are even stranger things. The "undefined" things can be a php function, system constant, or even some strange strings which look like regex, or even control characters in ASCII! The examples are as follows.
Declaration of PDO::() should be compatible with PDO::?)[CHAR1][CHAR2] where the [CHAR1] and [CHAR2] are SOHand ETX in ASCII.
Call to undefined method #^\\{\\w+\\}#::format()
Call to undefined method DateTime::format()
Undefined class constant 'PDO::ERRMODE_EXCEPTION'
(Other types of errors) Class Doctrine\DBAL\Driver\PDOStatement contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (Doctrine\DBAL\Driver\Statement::errorInfo, Doctrine\DBAL\Driver\ResultStatement::closeCursor)
Here are some more information: It usually happens every several hours, but can happen in half an hour or do not happen for half a day. My server handles about 1 http GET or POST request every second from one of the 6 remote machines.
This annoys me for a very long time and I would appreciate it if anyone could help me! Thank you so much!
I'm making additions to a Lemonstand v1 site, but only realised after a few days that the same error was occurring on the pages that I was amending; they seemed to take a while to load (on localhost) and then would error out with a 'Connection Reset' message. I'm pretty sure this kind of error is the result of a redirect loop or similar, and the local Apache error logs seem to bear this out:
[Sat May 24 14:35:23.487444 2014] [rewrite:warn] [pid 3492:tid 1744] AH00664: RewriteOptions: MaxRedirects option has been removed in favor of the global LimitInternalRecursion directive and will be ignored.
...repeated about 30 times. In both cases I was making a database call via the Db_ActiveRecord method upon which much of Lemonstand is based. Both calls were completely different, but essentially did the same thing: made a call to the database to find all instances of a record by ID or similar. For example:
$orders = Shop_Order::create()->where('customer_id=?', $this->customer->id)->order('order_datetime desc')->find_all();
Regardless of what I do with the resulting $orders (including doing nothing with it, just declaring it), this line alone causes the error. If I comment it out, the connection reset doesn't happen. This happens elsewhere with a completely unrelated module call which similarly uses Db_ActiveRecord:
$faqCategory = AhoyFaq_Category::create()->find_by_id($product->productFaqs_faq);
Again, if I just remove that call, the pages load as normal, without recursion issues.
If you're interested in taking a look at the .htaccess file, I've put it here - but it's a completely default .htaccess for Lemonstand, so I'm not sure that's where the problem lies. I've also put the full access log (at least, the list of errors following a page refresh) here.
I've got NO idea why a DB call would result in this kind of recursion, so if anybody has any clue, that would be great. Thanks guys.
This may be too obscure of an question, but I've been troubleshooting a baffling server error for hours and have pinned it down to the most bizarre issue; at this point I just want to know if anyone has ever had something similar occur, or might have any insight into what might possibly be happening.
The following line of code is triggering the error:
if ($Name=='ProxiedIP') { return true; }
This version runs without any problem at all:
if ($Name=='proxiedIP') { return true; }
It seems like somehow the token 'ProxiedIP' is fouling something up, but I cannot even think of how a string literal would be translated by the parser in a way that could hang the server up like this. BTW, I know for certain that $Name!='proxiedIP' and $Name!='ProxiedIP'.
Here's the entry in the apache error log:
[Fri Jan 18 18:15:12.924419 2013] [core:error] [pid 27676:tid 3427232831232] [client 12.345.67.890:34482] Premature end of script headers: index.php, referer: http://mySite.com/
I searched for 'ProxiedIP' as a keyword for every component that I can think of on my system and I'm coming up with nothing. The more imperative question for me though is how a string could somehow have this impact in a comparison check. Any ideas?
Also noteworthy that the PHP error log is completely silent about it. I'm enabling error output at the top of the page, but the script never finishes loading so that may be a factor. Here's how I'm setting it:
error_reporting(E_ALL);
ini_set('display_errors', 1);
Because the code worked here, it seems more likely that it could be something specific to the platform implementation. I'm running this on an instance of Gandi.net's 'Simple Hosting' service, which runs Varnish for application acceleration. It may also be worth mentioning that the code is being loaded in an iframe in a separate domain.
I am also doing some intensive work with the headers, and this seems like the greatest potential source of the problem, although the strange thing as far as I'm concerned is the way the error is being triggered. Also, there's no common header that I'm aware of called 'ProxiedIP', although that use conflict is the only thing that seems like it could make sense so far. Regardless, I don't see it.
To me, the real item of relevance is the mere fact that a string comparison is crashing the server. I've been programming in PHP for over 10 years and I have never had anything like this happen before. I'm trying to understand the logistics behind how it could even happen.
Update: I've tried the following variation, and it still produces the same result:
if ($Name === (strtoupper("p").'roxiedIP')) { return true; }
It was asked whether I would post the full code, but the script for the iframe side is 1400+ lines long so that's not really feasible. I'm adapting the segment in question to try running it in a new script though and will post the results.
I think the problem is with the variable $Name. Check whether it is getting assigned properly. Also check the code after if statement which is causing the problem.
Actually, I think your problem lies in the calling function, i.e. depending on the return value it does something "stupid" and PHP crashes.
Try replacing the if() with a hard return true or return false and see what happens.
As i get from your error, you are messing up the framework, the change in that if of yours triggers some output being called before the fw is allowed to make output. Just read it in more detail, you got it on the wrong train, that is not the cause of the error, it is the beginning of an unhallowed state of the fw.
Try running the script in a php debugger rather then using var dump.
Thanks for the posts, but it turned out to be a really convoluted scenario, where conditions several levels down the function chain caused unexpected behavior outside the scope of either function in question.
The actual issue was due to a condition check while parsing through output of a debug_backtrace() array in a totally separate process, which ironically was in place to prevent infinite recursion and instead triggered a similarly disruptive cascade of events that overran the allocated memory limit.
I originally posted because I was baffled by what truly seemed to be a string literal comparison doing something I didn't think should be possible, and wanted to understand what conditions could allow it to happen if so. I'm just glad the cause wasn't actually what it seemed to be. Thanks for helping to solve the puzzle.
Update: The true source of the error hinges on PHP's difficulty translating objects or arrays that contain references to themselves. I'm storing converted headers, direct header references, $_REQUEST[] and $_SERVER[] items, as well as logging messages and associated data in complex associative arrays. There are a lot of dynamic references between these items, particularly those involving the native PHP globals which I've made use of.
PHP has traditionally had problems managing self-referencing entities, and although improvements have been made, my particular situation is complex enough to send ReflectionClass into an endless loop while attempting to map these objects. I've fixed it by manually dereferencing the items as I'm polling them, but it's something to be aware of if needing to work with multiple $GLOBALS-related vars within a common array or referencing structure.
I am working on a website with a few friends, and recently, users have complained about a fairly important feature doing nothing but return a blank page. This only happens for some users, while other users are able to use it perfectly fine.
I consulted debug output and it turns out that a function is being declared twice. Once in the feature's main page (foo.php) and one in a file that gets require_once'ed. Obviously I'm on the right path to fixing it now, but what confuses me is that many people do not get this problem when visiting the page. Both function declarations are identical; the bodies seem to have been copy+pasted from one file to the other. Neither of these function declarations are conditional; they should both always take place.
Does anybody know of situations where PHP will be able to handle my mistake and make the page work anyway, despite this fatal error?
it may be the type of your function declaration is public,private or protected so that you might be not getting fatal errors by luck as till to my knowledge php does not allow function redeclaration in or by any means .
Sorry, PHP can never ignore fatal errors or function redeclarations, because in that cases, PHP will be confused as to what function declarations to consider, whether to use a old declaration or a new declaration.
Fatal Error means, there has something is so wrong, that PHP is confused as to what to do next, and therefore its your job to do it right.
Sorry PHP wont try to figure out as if two or more declarations were same and then ignore one of them. If this had to be done, the already slow PHP will become even more slower. So in the interest of community, you should consider writing a correct code, rather then asking PHP interpreter to correct this for you.