Infinite loop in clean_dirsize_cache()

[raubvogel]

Since WP 5.6 there exsists

<?php
function clean_dirsize_cache( $path ){}

at functions.php:7725.
There we have

<?php
        while ( DIRECTORY_SEPARATOR !== $path && '.' !== $path && '..' !== $path ) {
                $path = dirname( $path );
                unset( $directory_cache[ $path ] );
        }

at functions.php:7735 which loops „forever“ if $path is something like c:\dir\subdir on Windows.

<?php
$path = dirname( $path );

returns the parent path in each step and gets „stuck“ at c:\.

[raubvogel]

Btw. this breaks the media upload in my WordPress because media upload calls clean_dirsize_cache().

[audrasjb]

As per today's 5.6.1 bug scrub, moving this ticket to Future release pending further informations/context on the issue/bug (and a patch/unit tests).

[raubvogel]

Debug Screenshot 1

[raubvogel]

Debug Screenshot 1

[raubvogel]

Debug Screenshot 3

[ocean90]

#52292 was marked as a duplicate.

[codezen8]

Is there a schedule for this patch? I can confirm that media uploads are broken in WordPress 5.6.x for multi-site running on a Windows server. I have tested the patch above and can also confirm that with that line in place media uploads work as expected.

[sjlevy]

To comment also in support of this patch: it appears to work fine and needed to be re-applied after the last WP update.

I encountered the infinite loop issue on 3 of my windows server-based multisites a couple of months ago-- located the offending line of code, and then subsequently found this ticket. Thank you

[drosmog]

Bug continues to affect IIS in WordPress 5.7. Line changed to 7813 in functions.php.

[teachlynx]

Same as @drosmog, bug continues to affect IIS 10 in WordPress 5.7. Line changed to 7813 in functions.php.

[EkoJr]

May not be the most elegant solution, but it is a small simple change, and I'm a little surprised this ticket wouldn't have a high priority & got postponed to a future subversion considering it affects IIS servers and would appear to be a blocker bug for media.

Basically, the modified code compares the $last_path with the current $path, and if the $path is the same as it previously was in the previous iteration, it will then break out of the loop.

Original Code (WP 5.7)
wp-includes/functions.php:7812 > function clean_dirsize_cache( $path )

<?php
while ( DIRECTORY_SEPARATOR !== $path && '.' !== $path && '..' !== $path ) {
        $path = dirname( $path );
        unset( $directory_cache[ $path ] );
}

Modified Code

<?php
$last_path = '';
while ( DIRECTORY_SEPARATOR !== $path && '.' !== $path && '..' !== $path && $last_path !== $path ) {
        $last_path = $path;
        $path      = dirname( $path );
        unset( $directory_cache[ $path ] );
}

It's more of a conceptual solution, and someone may have a better answer. So, I am a bit hesitant creating a commit for this (plus, it's been awhile since I touched SVN).

[bartoszgrzesik]

I have problem with this bug. @EkoJr resolve is good to me.

[hellofromTonya]

Today is 5.8 Beta 1. This one needs tests and testing. Punting to 5.9 to continue progress towards resolution.

[teachlynx]

While there is probably a lot of things to do to push out 5.8, I am a bit disappointed that for a bug like this, which has a fix already checked by many users on this page, we have yet to wait for another release because this one "needs testing". For people like me who host their WP sites on IIS 10, we need to manually fix each of our multisite installs, so this is not hell, but it is clearly a waist of time.

[codezen8]

Replying to hellofromTonya:

Today is 5.8 Beta 1. This one needs tests and testing. Punting to 5.9 to continue progress towards resolution.

This is ridiculous that core WordPress files continue to need to be modified in a multisite environment because of one line of code that multiple people have tested.

What is the process that needs to be done here? I know I was not aware that this needed further steps in order to be included in 5.8. This is a critical bug that disables key functionality in a multisite environment and there have been many releases since it was identified.

[joegasper]

#53245 was marked as a duplicate.

[janthiel]

This also happens on Unix if the $path is empty. There should be added an empty check for $path

        if ( empty( $directory_cache ) || empty( $path ) ) {
                return;
        }

https://core.trac.wordpress.org/browser/tags/5.7.1/src/wp-includes/functions.php#L7815

[hellofromTonya]

Marking this early to ensure elevate attention for it: finalized testing, early commit, and then broad testing throughout the 5.9 cycle.

Switching ownership to me after talking with Sergey. I'll champion gathering the testing info, doing testing, and the code review to get this ticket ready for early commit.

[torralaq]

Never mind :)

[joseph.dickson]

This issue just popped up on one of my sites within a multisite. So far the others within the network have not ran into this problem.

Message on media upload: "Post-processing of the image failed likely because the server is busy or does not have enough resources. Uploading a smaller image may help. Suggested maximum size is 2500 pixels."

Is it possible that only a single site could be affected?

[SergeyBiryukov]

#53964 was marked as a duplicate.