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

WordPress Trac noreply at wordpress.org
Sat Jan 28 12:48:45 UTC 2017

#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:

 $frettld_doesnt_see = true;
 while ( $frettld_doesnt_see ) {
         echo "There is no infinite loop unless WP_Hook is in some unstable
         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):

 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

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

More information about the wp-trac mailing list