Opened 11 years ago
Last modified 5 years ago
#25648 reopened defect (bug)
plugin.php causes infinite loop and gigabytes of warning messages in error logs
Reported by: | ticktoo | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.6.1 |
Component: | Plugins | Keywords: | |
Focuses: | Cc: |
Description
We host several wordpress instances in a multi-user environment on our servers. Some installations cause regulary massive error log files with warnings like these:
PHP Warning: next() expects parameter 1 to be array, boolean given in [...]/html/wordpress/wp-includes/plugin.php on line 408
PHP Warning: current() expects parameter 1 to be array, boolean given in [...]/html/wordpress/wp-includes/plugin.php on line 404
After some googling I found out, that this behaviour is known for more than 10 month. So, if you could fix that, that'd be great.
Change History (23)
#3
@
11 years ago
Not sure what you found with google but this doesn't sound like a WordPress issue. I can't remember that I ever saw those errors in my log files.
I agree with Alex with the close. With the current information this seems more as a support request then a bug ticket.
Please report which action tag this is and what the output is of $wp_filter[$tag]
#4
@
11 years ago
I don't want Support and I don't know how to replicate this. I'm a hoster having logfiles with 11GB of senseless warnings from your application. On multiple instances. The kind of error message makes me feel of some missing validy checks like
next($var)
vs
if(is_array($var)) { next($var); }
or something like this.
I would greatly appreciate not to debug your whole application for an obvious misbehaviour. Nevertheless this affects instances that are not owned or controlled by myself. I cannot simply modify my customer's installations.
#5
@
11 years ago
The problem here is that its most likely a plugin that does weird things. So even when the warnings come from a WordPress file that doesn't mean that WordPress is the cause. In this case $wp_filter
is a global variable what everyone can change.
I can understand the issue of a logfile of 11GB and that you can't change the installation of a customer. For now you can only warn the customer that you get a lot of errors from the installation. Even if we make it more robust you still need to wait a while till the fix would be in a public release. To be sure this is a WordPress 3.6.1 installation?
#6
@
11 years ago
Yes. We encourage our coustomers on a regulary basis to keep their wordpress instances up-to-date. Therefor we precisley know the version of this specific instance. It would be nice if you could fix this for future versions. Thank you.
#8
@
11 years ago
There is no function named next() in WordPress core, so I'm sure (99%) it's a plugin or theme problem.
#9
@
11 years ago
Alex: next() is a PHP function that is used inside the WordPress function. The change is big that this issue is caused by a plugin.
The only question now is do we want to make that code more robust. Since it's a core feature I'm not sure if we want to.
#10
@
11 years ago
The issue appears to be introduced in WordPress SEO 1.4.16/18 to fix a conflict with NextGEN Gallery, and is reported to be fixed on the part of NextGEN Gallery:
http://wordpress.org/support/topic/new-bug-filling-up-log-files-taking-down-site-20gig-and-counting/page/2?replies=46#post-4692124
http://plugins.trac.wordpress.org/browser/wordpress-seo/tags/1.4.16/inc/class-sitemaps.php#L129
http://plugins.trac.wordpress.org/browser/wordpress-seo/tags/1.4.16/readme.txt#L106
http://plugins.trac.wordpress.org/changeset/775999/wordpress-seo#file25
We could add an is_array()
check in do_action()
before calling reset()
, current()
, or next()
, but I don't think we should hide developer errors.
#11
@
11 years ago
After some googling I found out, that this behaviour is known for more than 10 month.
I guess it's a reference to this post:
http://wordpress.org/support/topic/pluginphp-and-wp_filter-causing-an-infinite-loop
Well, maybe WordPress SEO isn't the only plugin that resets $wp_filter
global directly. The point is that no plugin should ever do that.
#12
@
11 years ago
Generating a warning here is the correct thing to do. The array elements in $wp_filter
should always be arrays. If a plugin is doing something stupid like setting one of the $wp_filter
elements to an invalid value, we shouldn't silence the error. This is untested, incorrect code on WordPress SEO's part.
#13
@
11 years ago
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from new to closed
#14
follow-up:
↓ 15
@
11 years ago
The problem is not to generate a warning. The problem is to generate Warnings within an infinite loop until the PHP MAX_EXECUTION_TIME takes effect. This is a serious issue as I can't guess, which defective Plugins a customer has installed.
So, am I right with my interpretation, that your point is, a 11GB Logfile full of catchable warnings caused by an infinite loop in one of your core component files is a valid behaviour?
#15
in reply to:
↑ 14
@
11 years ago
Replying to ticktoo:
So, am I right with my interpretation, that your point is, a 11GB Logfile full of catchable warnings caused by an infinite loop in one of your core component files is a valid behaviour?
Yes.
This warning happens to be triggered inside a WordPress core file, but the warning is caused by a plugin. It is not caused by WordPress. There is nothing for us to fix. Further, adding any defensive checks in plugin.php (such as is_array(), as stated above) would A) hide developer errors, and B) slow down an API that requires micro-optimization, as it is called called thousands of times per pageload.
It's unfortunate — I hope you are rotating your logs — but a logged warning is precisely the valid behavior here for a mistake such as this.
#16
@
9 years ago
I've picked up maintenance of a wordpress site that is experiencing this problem. The log fills with of these two errors
PHP Warning: next() expects parameter 1 to be array, boolean given in wp-includes/plugin.php on line 527, referer: wp-admin/admin.php?page=vimeography-edit-galleries
PHP Warning: current() expects parameter 1 to be array, boolean given in wp-includes/plugin.php on line 523, referer: wp-admin/admin.php?page=vimeography-edit-galleries
Until this error message is triggered:
PHP Fatal error: Maximum execution time of 30 seconds exceeded in wp-includes/functions.php on line 0
Adding "is_array()" in plugin.php seems to fix the immediate problem (wordpress dragging our server to halt and filling the error logs) but I could use some help tracking down the indirect problem of what code in the plugin is causing the problem, so I can file a bug report with the plugin author. Am I correct that what I should be looking for is plugin code referencing the $wp_filter variable? If so, any pointers to docs on what the plugin *should* be doing with that variable to avoid causing wordpress to enter an infinite loop?
#17
follow-up:
↓ 18
@
8 years ago
- Resolution invalid deleted
- Status changed from closed to reopened
Hi @steevithak did you find a cause and solution to this issue? I'm experiencing exactly the same issue as this with a particular site. error_log is building up to over 5GB with lines of PHP Warning: next(), maximum execution time 30 seconds etc..
Very hard to diagnose. If you could let me know that would be much appreciated.
#18
in reply to:
↑ 17
@
8 years ago
Replying to lsatdown:
No, I eventually gave up. We recommended to our client that they stop using the plugin that was causing the issue (in our case the vimeography plugin) and we switched them to another service. They now host videos on YouTube and use a YouTube plugin.
#20
@
8 years ago
@steevithak Thanks for the reply, how did you diagnose which plugin was causing the issue?
#21
@
8 years ago
In our case it was a Vimeo plugin but I gather from other comments that a variety of plugins and themes cause the same problem due to incorrect coding. I think if there's a Wordpress core bug here, it's that WP doesn't log the plugin that caused the problem, making it difficult to diagnose and fix. Maybe it's not possible for WP core to identify which plugins cause it?
#22
@
8 years ago
- Severity changed from normal to critical
I have the same problem and I can not solve it. But here, in addition to the bug reported by ticktoo, I'm also seeing in the log files the following:
PHP Fatal error: Call to undefined function _wp_filter_build_unique_id()
I've already tried the Matt Fiocca solution in https://wordpress.org/support/topic/pluginphp-and-wp_filter-causing-an-infinite-loop/ Without success, nothing has changed :(
Can someone help me?
I have seen that access to "post_tag" taxonomy (the tags of posts and custom posts) is extremely slow.
#23
@
8 years ago
- Severity changed from critical to normal
@moisb if _wp_filter_build_unique_id()
is missing, it sounds like your WordPress install is incomplete or corrupt. Try re-installing your files (either from the Dashboard updates page, or manually by extracting the release ZIP over the top of your existing site).
Trac is not an avenue for support, please open a thread on the support forums if you need additional help.
so how to replicate this? what are the steps to have the same error?