[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:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+-----------------------------
Changes (by dd32):

 * keywords:  reporter-feedback needs-patch dev-feedback => needs-patch


Comment:

 With no further details two years on since I last looked at this, here's
 my best idea of what's happening:
  - 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
 [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-
 hook.php?rev=42746&marks=271#L264 line 271] rather than being prevented by
 [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-
 hook.php?rev=42746&marks=265#L264 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

 Although IMHO it's a bad change, I'm going to support the suggested fix
 from the original ticket, even with the potential performance aspects of
 it:
 {{{
 } while ( ! is_null( $this->iterations[ $nesting_level ] ) && false !==
 next( $this->iterations[ $nesting_level ] ) );
 }}}
 That'll still produce several warnings, but won't be stuck in the endless
 loop.

 The alternative is to add something on
 [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-
 hook.php?rev=42746&marks=273#L264 line 273] prior to the loop, however, I
 suspect that if my above thoughts are correct, it's possible to trigger
 the issue mid-hook-loop in addition to prior to the loop (but the proof of
 that would be buried in the GB's of logs that this creates in those
 obscure scenario's).

 I'm not going to reassign the milestone, in the hope that another
 committer will come along and own the fix and tests needed for it.

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