[wp-trac] [WordPress Trac] #39338: class-wp-hook.php - apply_filters() infinite loop

[WordPress Trac]

#39338: class-wp-hook.php - apply_filters() infinite loop
--------------------------+-----------------------------
 Reporter:  frettled      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  Plugins       |     Version:  4.7
 Severity:  critical      |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+-----------------------------

Comment (by pcamepc):

 Hi,

 Does your websites runs on cPanel by any chance ?

 We are currently experiencing the issue on websites that haven't been
 modified for a few months. The only change was a cPanel update made today
 on our server :

 Change Log for 80.0.22
 Entry: 2019-07-16, 01:30 (UTC)
 [TSR-2019-0004]

 I'm thinking that maybe the update interrupted a process and started the
 infinite loop. Like @dd32 suggested :

 * A long running process is triggering a PHP timeout
 * The timeout occurs when WP_Hook is in a specific state
 * PHP's Garbage collector starts cleaning up memory, which ultimately
 results in either $this->callbacks or $this->iterations being null
 (although sometimes also being set to an int, which I suspect could also
 mean this is down to corrupt memory).
 * This is possibly triggered by $nesting_level = $this->nesting_level++;
 allocating memory, which then removes the memory used by $this->callbacks
 - which explains why the PHP Warnings start at line 271 rather than being
 prevented by line 265
 * PHP attempts to cleanly shut down but allows a short grace period, which
 ultimately results in this loop running endlessly during that period

 Maybe a cPanel update could trigger this issue ?

 Thanks

 Replying to [comment:55 mordisko]:
 > This is still a problem.
 >
 > As a hosting provider we have hundreds of customers affected by this.
 The main problem is that an endless loop of errors generates thousands of
 gigabytes of error logs, which causes customers' quota to fill, which in
 turn ends up affecting more services than the WordPress itself.
 >
 > I understand the sentiment of trying to fully fix the underlying problem
 instead of applying a patch to prevent it from ever happening, but I do
 think that there has to be some middle ground here. How does having an
 endless loop help to find the issue? doesn't it make sense to stop the
 loop at some point, register or throw an error and move on?
 >
 > So far we have been unable to reproduce the error (and we devoted a lot
 of time to this) and the fact that this has been opened for quite a while
 now is forcing us to stop logging php errors altogether, which is a useful
 default feature for our end customers.
 >
 > We have been trying to diagnose this for a while now, but so far we
 haven't been able to find any patterns on plugins, themes or WP/php
 versions.
 >
 > It would be good to have a solution for this as it seems kind of strange
 to allow something like this to ever happen.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/39338#comment:56>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform