[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:
     Type:  defect (bug)                   |      Status:  new
 Priority:  normal                         |   Milestone:  4.7.3
Component:  Plugins                        |     Version:  4.7
 Severity:  normal                         |  Resolution:
 Keywords:  reporter-feedback needs-patch  |     Focuses:
-------------------------------------------+--------------------

Comment (by gitlost):

 `xdebug.so` is only ~1.2M so disk space shouldn't be an issue! Also it's
 per-server, not per-WP install. Also if the error is reproducible for you
 then you'd only have it install it once you encounter it. Anyway it's an
 option to consider next time it happens. It would I think really help to
 understand the issue. However...

 >The PHP version in question is the latest 5.5 with security patches
 backported from 5.6

 So you're running some distro's LTS build of PHP? Bit of a red flag, but
 probably nothing...though it probably complicates using `Xdebug`.

 >we already know where the problem is and how to fix it: don't run
 infinite loops. Never!

 It's been said before but I'll repeat it:

 {{{#!php
 <?php
 $frettld_doesnt_see = true;
 while ( $frettld_doesnt_see ) {
         echo "There is no infinite loop unless WP_Hook is in some unstable
 condition."
         echo "How does WP_Hook get into some unstable condition?"
         echo "Nobody knows."
 }
 }}}

 I've been able to semi-reliably put `WP_Hook` into an unstable condition
 by getting the max execution time to trigger during the `ksort()` in
 `WP_Hook::add_filter()` (using PHP 7.0.13):

 {{{#!php
 set_time_limit( 1 );
 for ( $i = 0; $i < 100000; $i++ ) {
         add_action( 'shutdown', '__return_true', $i );
 }
 }}}

 which sometimes leaves the `$this->callbacks` array with duplicate
 entries, which then causes PHP warnings (but not infinite) about undefined
 offsets and invalid arguments in the inner loop of
 `WP_Hook::add_filters()` when it's being run in `shutdown_action_hook()`.

 It's an unrealistic scenario of course but it does demonstrate that
 `WP_Hook` can be put into an unstable condition "naturally", and that
 calling complicated code like `WP_Hook` in the shutdown routine could
 cause problems. So it might be worth doing the "shutdown" filters in some
 fail-safe manner, perhaps something like the opposite of
 `WP_Hook::build_preinitialized_hooks`...

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