wp_is_stream Crashing the server

I have posted our experience in this thread: https://www.ads-software.com/support/topic/fatal-error-allowed-memory-size-of-11/

We have temporarily fixed by rolling back to WordPress version 4.9.6, as I believe the issues is related to changes to wp-includes\functions.php in the latest version.

I’m trying to find out how to report this to the core developers.

This is actually an old elusive bug https://bugs.php.net/bug.php?id=72451 that is most likely associated with the use of a Windows server.
I see it from time to time on my sites, but after the last update, sites really began to fall almost constantly, so I had to “patch” the wordpress files as a temporary measure.

My environment
Windows Server 2008 R2
PHP 7.1.18
Apache/2.4.28 (Win64) OpenSSL/1.0.2l

Yes. Windows server.

@bezpekacom so how did you “patch” the wordpress files?.

I can’t seem to find anything specific on that thread.

For me the error is on LAMP server.
it is probably related to change in wp_normalize_path, which calls wp_is_stream

@breakoftheec
just replace string
$wrappers = stream_get_wrappers();
with
$wrappers = array(‘https’, ‘ftps’, ‘compress.zlib’, ‘compress.bzip2’, ‘php’, ‘file’, ‘glob’, ‘data’, ‘http’, ‘ftp’, ‘phar’, ‘zip’); // your array may be different
this is by no means a solution to the problem, but simply a temporary fix so that the sites can work

@bezpekacom thanks.
Yes I know the implications of modifying WP core files.

Same problem here

Windows 10
running WampServer 3.1.2
PHP 7.0.23
Apache 2.4.29

Only started happening after upgrade to WordPress 4.9.7

I had something similar months ago, when I switched to PHP7.
I was supponsing they fixed it with PHP 7.1.12 as I nver had troubles since that and Apache 2.4.x
Last week I upgraded to latest Apache 2.4.x and latest PHP 7.1.x, and installing a new site using WP got me to the memory limit exhausted error again.
I patched the wp function as above. Now I’ll check if the sites will stay up or not.
So I’m not sure if it’s the latest WP or just latest PHP / Apache…

Hello. I’m quite new here but would like to add my findings.
I too had this huge memory allocation problem (million’s of terabites) and continous crashing of my localserver (bitnami wamp stack 7.1.14). Rolling back to WP 4.9.6 did however not solve the case, but made the problem lighter.
Reading all the threads it looks like a WP core bug? Am I right?
Can someone tell me the wordpress team is working on this issue? The problem did however not occur on my productionsite yet (apache). Feels like a matter of time this will happen though ??

Hello. Core is investigating this issue, and there is a ticket for it.

At present, this doesn’t appear to be specifically a WordPress bug, but it is possible that some of the changes in WordPress 4.9.7 might cause the underlying PHP bug to trigger more often.

In other words, the problem is in PHP itself, and we’re not sure what causes it, exactly.

However, we can be fairly confident that the problem is not specific to 4.9.7, as there are reports of the same issue from over a year ago. Here’s one, for example: https://wordpress.stackexchange.com/questions/267797/allowed-memory-size-of-268435456-bytes-exhausted-tried-to-allocate-714649184090/267799

The issue seems to be some kind of memory corruption in PHP or Apache. I have not been able to find any more specific details on the underlying cause.

A workaround would be as @bezpekacom mentioned above. The wp_is_stream() function’s purpose is to check to see if a path passed to it is a stream. The stream_get_wrappers function in PHP is called upon to do this.

Now, the reason this is used is that different PHP installs have different kinds of support for different things. It seems that due to the bug in PHP, it is possible for this function to return corrupted data when the server gets a lot of hits or when some kind of memory corruption occurs. This would happen over time, not immediately.

The workaround bezpekacom mentions above would prevent WordPress from calling that function, thus preventing the problem. Having just a string of your wrappers would work just fine for the same purpose, more or less.

If you are having this problem in production, then that workaround will fix the issue for you for the time being. Reverting to 4.9.6 is not necessary, nor indeed is it a solution to the problem. As the issue is in PHP itself, reverting to 4.9.6 will only reduce the occurrence of the issue, not eliminate it entirely.

The only *fix* would be for the bug in PHP to be found, and for you to update your PHP to the latest version. PHP’s bug tracker says that they fixed it, so first, try to update to the latest version of PHP that you have available.

If that fails, then deploy the workaround until such time as PHP is corrected. A patch for this may be coming in 4.9.8, but as the bug is in PHP, there’s nothing WordPress can do to permanently fix the issue. We have to work with the PHP folks to figure out the problem and work towards a solution.

Just change function wp_is_stream on wp-includes/functions.php:

function wp_is_stream( $path ) {
    $wrappers = stream_get_wrappers();
    // The first argument is ve-e-ery long (length=7471216), it causes problem
    if (!empty($wrappers) && strlen($wrappers[0]) > 100) {
        array_shift($wrappers);
    }
    
    $wrappers_re = '(' . join('|', $wrappers) . ')';

	return preg_match( "!^$wrappers_re://!", $path ) === 1;
}

• This reply was modified 6 years, 4 months ago by hatand.

A better “fix” for this issue is available in WordPress 4.9.8 beta 2, and it will be in the final version of 4.9.8:

WordPress 4.9.8 Beta 2

Now, note that this is not a “fix” as such a thing is not really possible. The underlying issue is a PHP one, and not something that we can actually fix.

However, the problem is significantly reduced by the upcoming change. The way that this is done is to avoid calling the stream_get_wrappers function as much as possible.

The problem is one of memory corruption. The stream_get_wrappers function is supposed to simply return an array of stream wrapper types. For the most part, it does that. It seems that on certain configurations, calling this function can eventually lead to some kind of memory corruption. Thus, it returns an invalid pointer in the results, leading to random garbage being there. This garbage can get interpreted as an extremely large string, thus leading to the memory problems when that data is accessed. By avoiding calling stream_get_wrappers as much as possible, this can be delayed, or reduced in frequency.

The problem configuration seems to be unknown at this time. The various reports are all on Windows based hosting, usually using Apache as the server. I suspect that using the mod_php type configuration would also be needed for this problem to occur, but I can’t reproduce it myself.

In any case, try the latest version of WordPress 4.9.8, and that should eliminate the issue for you.

@bezpekacom ; Thank you from me as well.

Yes, I appreciate it’s a somewhat hacky short-term fix that isn’t ideal from a maintenance point of view, but it seems to be working for me just now, unlike some of the other solutions!

@otto42; “The various reports are all on Windows based hosting.”

It’s not just Windows. According to this comment and the one which follows it, it’s also happening on some Linux installations.

(I appreciate that this doesn’t ultimately change the fact that- as you note- it’s apparently a bug in PHP itself, rather than WordPress.)

I’ve been experiencing this issue repeatedly with WP 4.9.7 on Win7 64-bit Apache 2.4 and PHP 7.1.8. It occurs occasionally loading various admin pages, and seems to occur regularly if I go to “Dashboard->Updates” immediately after logging in.

After restarting Apache, the issue doesn’t seem to recur during that session regardless of which backend tasks I do, although I haven’t tested that for an extended period.

Since replacing the call to stream_get_wrappers with an array of values, I have not seen the issue occur. Thanks for pointing out this simple work-around.