Extreme memory leak related to wp_is_stream in wp-includes/functions.php in WordPress 4.9.7

[timbowesohft]

Changes to wp-includes/functions.php in the WordPress 4.9.7 update, specifically wp_is_stream (line 5233), appear to be causing abnormal memory issues for a number of users on the support forum following the update.

<?php
function wp_is_stream( $path ) {
    $wrappers = stream_get_wrappers();
    $wrappers_re = '(' . join('|', $wrappers) . ')';
 
    return preg_match( "!^$wrappers_re://!", $path ) === 1;
}

Users are encountering errors like this:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 8459550600754132419 bytes) in \wp-includes\functions.php

Note that in this case it is trying to allocate 8 million terabytes (!) of memory -- though most users are encountering figures closer to 2000GB, which is still abnormal.

I have reverted WordPress to version 4.9.6, and over the past hour of monitoring CPU/Mem/disk has remained stable and our users are reporting service as normal again.

The are a number of topics open on the support forum reporting this issue.

[johnbillion]

Thanks for the report @timbowesohft . Can you provide a link to some of the forum threads please?

[timbowesohft]

Yes, of course. Here are a couple:

​https://wordpress.org/support/topic/wp_is_stream-crashing-the-server/

​https://wordpress.org/support/topic/fatal-error-allowed-memory-size-of-11/

[JPry]

My first thought is that this may be related to #43054. The fix for that (r42432) is in trunk, but not the 4.9 branch.

[johnbillion]

@JPry Good spot, that looks like a likely culprit.

cc @dd32 as an FYI.

[timbowesohft]

Thanks for picking this up.

Not sure if this helps, but one of our users encountered this warning when attempting to log in to their account while we were running 4.9.7, in between the fatal error:

Warning: preg_match(): Null byte in regex in \wp-includes\functions.php on line 5233

[Webaxones]

Hi, I think I got the same :

Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 12382903167681155619 bytes) in F:\www\myclient\wp-includes\functions.php on line 5231

Local, WampServer, just after 4.9.7 update :)

Got it sometimes with one plugin, sometimes with another one.
Of course my PHP parameters are high enough (memory limit : 1Go)

[Arioman]

i have the same problem with functions.php on line 5231

Fatal error: Allowed memory size of 1073741824 bytes exhausted

i try disabling all plugins , themes and no success

even install fresh wp 4.9.7 without any addons and still get this error on local wamp64

it doesn't matter how much memory limit i set | my Hosting message me for using too many Resource of ram & Cpu too

[sebastien@…]

Hello

On this version of WordPress (the dev one):
​https://github.com/WordPress/WordPress

the

wp_is_stream()

function is quite different...

<?php
/**
 * Test if a given path is a stream URL
 *
 * @since 3.5.0
 *
 * @param string $path The resource path or URL.
 * @return bool True if the path is a stream URL.
 */
function wp_is_stream( $path ) {
        $wrappers    = stream_get_wrappers();
        $wrappers    = array_map( 'preg_quote', $wrappers );
        $wrappers_re = '(' . join( '|', $wrappers ) . ')';

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

is it normal?
is this change fix the problem ?

[psykro]

From a comment by @bezpekacom on one of the support tickets, this seems to be a PHP 7 bug on Windows servers

​https://bugs.php.net/bug.php?id=72451

UPDATE: Seems it was fixed in early 2017 but has been reported again on PHP 7.2.0

[dd32]

Replying to johnbillion:

@JPry Good spot, that looks like a likely culprit.

cc @dd32 as an FYI.

FWIW it looks like a backport is needed, but that the PHP 7.2 + Windows super-long-string issue is unavoidable by WordPress and will need hosts to update to a non-affected version of PHP (if there is one)

[ddenev]

Replying to sebastien@…:

Hello

On this version of WordPress (the dev one):
​https://github.com/WordPress/WordPress

the

wp_is_stream()

function is quite different...

<?php
/**
 * Test if a given path is a stream URL
 *
 * @since 3.5.0
 *
 * @param string $path The resource path or URL.
 * @return bool True if the path is a stream URL.
 */
function wp_is_stream( $path ) {
        $wrappers    = stream_get_wrappers();
        $wrappers    = array_map( 'preg_quote', $wrappers );
        $wrappers_re = '(' . join( '|', $wrappers ) . ')';

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

is it normal?
is this change fix the problem ?

Nope, this does not fix the memory explosion problem. At least for me on Win7 64-bit. The only fix that works so far is the one suggested by "bezpeka.com" here - ​https://wordpress.org/support/topic/wp_is_stream-crashing-the-server/, although it's rather a temporary hack.

[sedros]

Hi,
I have the same issue on Gentoo Linux. My site is randomly not loading and in apache logs I see a lot of entries of this kind:

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 3336129794746101211 bytes) in /var/www/(...cut out...)

Problems started after upgrading to Wordpress 4.9.7.

[pandraka]

Is there a time estimate as to when a fix will be available. My site is experiencing a Fatal error:

Fatal error: Allowed memory size of 2097152000 bytes exhausted (tried to allocate 17179869292 bytes) in E:\Apache2\htdocs\nwgvcop\wp-includes\functions.php on line 5231

I'm trying to determine whether to wait for a fix or rollback wordpress to 4.9.6

Any suggestions?

[ddenev]

Replying to pandraka:

Is there a time estimate as to when a fix will be available. My site is experiencing a Fatal error:

Fatal error: Allowed memory size of 2097152000 bytes exhausted (tried to allocate 17179869292 bytes) in E:\Apache2\htdocs\nwgvcop\wp-includes\functions.php on line 5231

I'm trying to determine whether to wait for a fix or rollback wordpress to 4.9.6

Any suggestions?

1. Apply the workaround in the link I provided above
2. Stop automatic updates by adding define( 'WP_AUTO_UPDATE_CORE', false ); to wp-config.php
3. Wait for a proper fix

[JPry]

Patch for the 4.9 branch

[JPry]

Replying to ddenev:

1. Apply the workaround in the link I provided above

Hard-coding the stream wrappers is not the best solution. You could be breaking functionality that a plugin is relying on.

2. Stop automatic updates by adding define( 'WP_AUTO_UPDATE_CORE', false ); to wp-config.php

You should only do this if you remember to remove it later. Disabling auto updates is usually not a good option, especially since 4.9.7 is a security release, not just a bug fix release.

3. Wait for a proper fix

For those experiencing the issues, can you confirm whether the attached patch fixes your issues? I believe the issue actually stems from the call to preg_match().

[ddenev]

Replying to JPry:

1. Apply the workaround in the link I provided above

Hard-coding the stream wrappers is not the best solution. You could be breaking functionality that a plugin is relying on.

Agree, not the best solution when everything works fine. But what was the best solution (before you provided the patch) when we need our sites up and running? Reverting to 4.9.6 did not solve the problem either - less crashes but still crashes.

2. Stop automatic updates by adding define( 'WP_AUTO_UPDATE_CORE', false ); to wp-config.php

You should only do this if you remember to remove it later.

Yes, that is the case, thank you :).

[ddenev]

I can confirm that the provided patch does NOT solve the problem for me. PHP still crashes, this time the error in the debug.log is:

PHP Fatal error:  Possible integer overflow in memory allocation (4 * 6661789698600755555 + 32) in wp-includes\functions.php on line 5237

5237 is the line where this code is:

$wrapper = preg_quote( $wrapper, '!' );

I also get an error in the Windows event log:

Faulting application name: httpd.exe, version: 2.4.33.0, time stamp: 0x5abb6dc6
Faulting module name: php7ts.dll, version: 7.1.19.0, time stamp: 0x5b2aeea0
Exception code: 0xc0000005
Fault offset: 0x000000000012e030
Faulting process id: 0x4580
Faulting application start time: 0x01d419513cc36a2e
Faulting application path: D:\Applications\Apache\bin\httpd.exe
Faulting module path: D:\Applications\PHP7\php7ts.dll
Report Id: 83af3ff0-8544-11e8-9f0f-005056c00008

Note: if you use OPCache, you need to restart Apache so that the changes take effect.

[pandraka]

I can confirm that the patch recommended by JPry didn't work for our WP install. This is the error we got:

Fatal error: Possible integer overflow in memory allocation (4 * 7810207576837218661 + 32) in E:\Apache2\htdocs\nwgvcop_dev\wp-includes\functions.php on line 5232

Pat

[dd32]

For those experiencing this issue:

• Can you detail the version of PHP you're using? 7.0.something? 7.1 / 7.2? Does changing that to a later version help?
• What operating system & Version (Windows Server 20... or similar)
• What PHP extensions do you have active (You can find this in the PHP Info output)

[dd32]

As a possible work-around for now, we could skip calling stream_get_wrappers() in wp_is_stream() when possible - For most users, where streams aren't actually used, it'll avoid this issue for the majority of users.

Something like:

function wp_is_stream( $stream )
   if  $stream does not contain '://':
      return $stream cannot be a Stream.
   endif

   $wrappers = stream_get_wrappers();
   ... All existing logic, probably with r42432 backported.

[ddenev]

Hi @dd32,

Thank you for responding! Here is my info:

== Server Environment ==
    Web server:	Apache/2.4.33 (Win64) OpenSSL/1.1.0h PHP/7.1.19 (Windows NT SOLO AMD64 build 7601 (Windows 7 Enterprise Edition Service Pack 1))
    Memory limit:	256M
    PHP version:	7.1.19
    MySQL version:	5.7.22
    Curl version:	7.59.0 / SSL: OpenSSL/1.0.2o / libz: 1.2.8
    OpenSSL version:	OpenSSL 1.0.2o 27 Mar 2018
    MCrypt:	Yes
    ZipArchive::addFile:	Yes
    zip executable found:	No
    Apache modules:	core, http_core, access_compat, alias, authz_core, autoindex, dir, env, include, isapi, log_config, mime, negotiation, php7, rewrite, setenvif, so, socache_shmcb, ssl, win32, mpm_winnt

== WordPress Environment ==
	Version: 4.9.7
	Site URL: https://bayer-machines.ddev
	Home URL: https://bayer-machines.ddev
	WP Multisite: No
	Max Upload Size: 32 MB
	Memory limit: 128M
        Memory limit: 256M
	Permalink Structure: /%postname%/
	Language: en-US
	Timezone: Europe/Sofia
	Debug Mode: Inactive

== User ==
	Role: administrator
	WP Profile lang: en_US
	User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

PHP Streams (from phpinfo()):

Registered PHP Streams             : php, file, glob, data, http, ftp, zip, compress.zlib, compress.bzip2, https, ftps, phar
Registered Stream Socket Transports: tcp, udp, ssl, sslv3, tls, tlsv1.0, tlsv1.1, tlsv1.2
Registered Stream Filters          : convert.iconv.*, mcrypt.*, mdecrypt.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk, zlib.*, bzip2.*

PHP Extensions:

c:\>php -m
[PHP Modules]
bcmath
bz2
calendar
Core
ctype
curl
date
dom
filter
gd
hash
iconv
json
libxml
mbstring
mcrypt
mysqli
mysqlnd
openssl
pcre
PDO
pdo_mysql
Phar
readline
Reflection
session
SimpleXML
soap
sockets
SPL
standard
tokenizer
wddx
xdebug
xml
xmlreader
xmlrpc
xmlwriter
Zend OPcache
zip
zlib

This is the latest PHP 7.1 version and I don't want to change to 7.2 yet (other problems) - so no benefit in upgrading to 7.2.

[pbiron]

implements @dd32's suggestion in https://core.trac.wordpress.org/ticket/44532#comment:27

[pbiron]

Can those who are experiencing this problem please apply 44532.1.diff and let us know if it reduces the occurrence of the problem?

[itowhid06]

So, I don't want to sound silly, but is there a slightest chance that this issue might be causing due to windows directory separator ?? previously I've faced a problem due to windows directory separator and using something like

str_replace('\\', '/', $path);

solved the issue. Any thoughts?

Edit: sorry, not sure why the reporter-feedback tag got removed. I'm adding it again.

[pbiron]

Replying to itowhid06:

So, I don't want to sound silly, but is there a slightest chance that this issue might be causing due to windows directory separator ??

Not silly at all, given that the problem only seems to affect Windows hosts.

But, no, I don't think that's a contributing factor.

[dontstealmyfish]

Replying to pbiron:

Can those who are experiencing this problem please apply 44532.1.diff and let us know if it reduces the occurrence of the problem?

Added the change and will see if it helps. Should have a definite answer by tomorrow.

[sedros]

Replying to pbiron:

Replying to itowhid06:

So, I don't want to sound silly, but is there a slightest chance that this issue might be causing due to windows directory separator ??

Not silly at all, given that the problem only seems to affect Windows hosts.

Hey, I'm affected on Linux as mentioned before.

[sedros]

My PHP:
dev-lang/php-7.1.12::gentoo was built with the following:
USE="acl apache2 berkdb bzip2 cli crypt ctype curl fileinfo filter gd gdbm gmp hash iconv imap ipv6 json ldap ldap-sasl mysql mysqli nls opcache pdo phar posix postgres readline session simplexml sockets spell ssl threads tokenizer truetype unicode xml xmlreader xmlwriter zip zlib -bcmath -calendar -cdb -cgi -cjk -coverage -debug -embed -enchant -exif -firebird -flatfile -fpm -ftp -inifile -intl -iodbc -kerberos -libedit -libressl -mhash -mssql -oci8-instant-client -odbc -pcntl -phpdbg -qdbm -recode (-selinux) -sharedmem -snmp -soap -sqlite -systemd -sysvipc -test -tidy -wddx -webp -xmlrpc -xpm -xslt" ABI_X86="(64)"

www-apps/wordpress-4.9.7::gentoo was built with the following:
USE="akismet themes vhosts -examples" ABI_X86="(64)"

OS: Gentoo Linux

[ddenev]

I can confirm that the provided patch DOES indeed solve the crashes.

I enabled debug mode with XDebug and set a breakpoint after the return statement to check if it will be hit. I did testing for half a day and the breakpoint was never hit, so it looks promising.

What would be the scenarios in which

if ( false === strpos( $path, '://' ) )

would return true and then we will have the crashes again?

[pbiron]

Replying to ddenev:

I can confirm that the provided patch DOES indeed solve the crashes.

Thanx for the confirmation.

It's important to note that the patch does not solve the problem, which is actually a bug in PHP's ​stream_get_wrappers()). Rather, it is simply intended to reduce the likelihood that that PHP bug will be surfaced in WP. See below for an explantation of how the patch intends to achieve that.

We still need confirmation from others who are experiencing this problem that the patch reduces the occurrences of the problem for you as well.

What would be the scenarios in which

if ( false === strpos( $path, '://' ) )

would return true and then we will have the crashes again?

Let me see if I can explain what the patch is intened to do.

Many (most?) of PHP's file-related functions (e.g., ​fopen(), ​file_get_contents(), etc) not only operate on files, but are able to seemlessly operate on URLs (referred to, in this context, as streams) as well:

• file_get_contents( '/path/to/file.txt' )
• file_get_contents( 'https://example.com' )
• etc.

In some cases, WP needs to do extra or special processing when asked to operate on a stream; hence, the existence of ​wp_is_stream().

In the vast majority (99% ?) of cases, the $path passed to wp_is_stream() is a file system path and not a URL so there is no need to call PHP's stream_get_wrappers(), which returns an array of protocols or URL "schemes" that PHP supports, to test whether the URL is a stream that PHP can handle.

To the best of everyone's understanding, the simple act of calling stream_get_wrappers() does not cause the PHP bug to surface, but repeated calling of it can.

Since ALL URL's will contain the substring :// and NO file system paths will, the

if ( false === strpos( $path, '://' ) ) {
        return false;
}

test in the patch avoids calling PHP's stream_get_wrappers() in the vast majority of cases.

Changes in WP 4.9.7 drasticly increased the number of times wp_is_stream() is called in a typical WP request; hence, drastically increasing the number of times PHP's stream_get_wrappers() is called. This appears to be why there have been so many more reports of the problem since the release of 4.9.7.

So the hope is that by reducing the number of times stream_get_wrappers() is called, the patch will return the number of times the PHP bug surfaces in WP to pre-4.9.7 levels (and maybe even lower).

Does that explanation help?

[ddenev]

Dear @pbiron

thank you very much for the detailed explanation!

Yes, I understand what the patch does and that the root of the problem lies in PHP rather than in WP. I also understand that this patch will significantly reduce the number of calls to the problematic PHP function.

The only thing that I still do not understand (and that was actually my initial question but I guess I did not state it well enough) is the following (and that is based purely on curiosity as 99% is pretty good success rate :)

Replying to pbiron:

In the vast majority (99% ?) of cases, the $path passed to wp_is_stream() is a file system path and not a URL so there is no need to call PHP's stream_get_wrappers(), which returns an array of protocols or URL "schemes" that PHP supports, to test whether the URL is a stream that PHP can handle.

In what cases (the mentioned 1%) the $path variable will NOT be a file system path? Any potential scenarios and use cases?

Thanks again for the help!

[pbiron]

Replying to ddenev:

The only thing that I still do not understand (and that was actually my initial question but I guess I did not state it well enough) is the following (and that is based purely on curiosity as 99% is pretty good success rate :)

In what cases (the mentioned 1%) the $path variable will NOT be a file system path? Any potential scenarios and use cases?

Some plugins may call WP core functions that eventually call wp_is_stream() with a URL as $path. You may not have any such plugins active and so would never see that case. Sorry I can't be more specific than that.

[ddenev]

Unfortunately, I got another crash today. Here is the Apache error log:

[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 17179869232 bytes) in D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\functions.php on line 5158, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP Stack trace:, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP   1. {main}() D:\\Projects\\Websites\\bayer-machines\\web\\index.php:0, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP   2. require() D:\\Projects\\Websites\\bayer-machines\\web\\index.php:17, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP   3. require_once() D:\\Projects\\Websites\\bayer-machines\\web\\wp-blog-header.php:13, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP   4. require_once() D:\\Projects\\Websites\\bayer-machines\\web\\wp-load.php:37, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP   5. require_once() D:\\Projects\\Websites\\bayer-machines\\web\\wp-config.php:111, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP   6. do_action() D:\\Projects\\Websites\\bayer-machines\\web\\wp-settings.php:327, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP   7. WP_Hook->do_action() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\plugin.php:453, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP   8. WP_Hook->apply_filters() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\class-wp-hook.php:310, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP   9. {closure:D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\bootstrap.php:45-53}() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\class-wp-hook.php:286, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  10. Codelight\\GDPR\\Setup->__construct() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\bootstrap.php:51, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  11. Codelight\\GDPR\\Setup->runComponents() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\src\\Setup.php:36, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  12. Codelight\\GDPR\\Container->make() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\src\\Setup.php:87, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  13. Codelight\\GDPR\\Container->resolve() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\vendor\\illuminate\\container\\Container.php:575, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  14. Codelight\\GDPR\\Container->build() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\vendor\\illuminate\\container\\Container.php:608, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  15. ReflectionClass->() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\vendor\\illuminate\\container\\Container.php:762, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  16. Codelight\\GDPR\\Components\\WordpressComments\\WordpressComments->__construct() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\vendor\\illuminate\\container\\Container.php:762, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  17. Codelight\\GDPR\\Components\\WordpressComments\\WordpressComments->setup() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\src\\Components\\WordpressComments\\WordpressComments.php:17, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  18. Codelight\\GDPR\\Options\\Options->get() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\src\\Components\\WordpressComments\\WordpressComments.php:22, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  19. get_option() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\src\\Options\\Options.php:25, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  20. QM_DB->get_row() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\option.php:98, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  21. QM_DB->query() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\wp-db.php:2413, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  22. QM_DB->query() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\query-monitor\\wp-content\\db.php:100, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  23. QM_DB->_do_query() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\wp-db.php:1813, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  24. QM_DB->get_caller() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\wp-db.php:1931, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.857012 2018] [php7:notice] [pid 29440:tid 860] [client 192.168.88.11:22465] PHP  25. wp_debug_backtrace_summary() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\wp-db.php:3412, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 17179869232 bytes) in D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\functions.php on line 5158, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP Stack trace:, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP   1. {main}() D:\\Projects\\Websites\\bayer-machines\\web\\index.php:0, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP   2. require() D:\\Projects\\Websites\\bayer-machines\\web\\index.php:17, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP   3. require_once() D:\\Projects\\Websites\\bayer-machines\\web\\wp-blog-header.php:13, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP   4. require_once() D:\\Projects\\Websites\\bayer-machines\\web\\wp-load.php:37, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP   5. require_once() D:\\Projects\\Websites\\bayer-machines\\web\\wp-config.php:111, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP   6. do_action() D:\\Projects\\Websites\\bayer-machines\\web\\wp-settings.php:327, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP   7. WP_Hook->do_action() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\plugin.php:453, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP   8. WP_Hook->apply_filters() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\class-wp-hook.php:310, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP   9. {closure:D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\bootstrap.php:45-53}() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\class-wp-hook.php:286, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  10. Codelight\\GDPR\\Setup->__construct() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\bootstrap.php:51, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  11. Codelight\\GDPR\\Setup->runComponents() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\src\\Setup.php:36, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  12. Codelight\\GDPR\\Container->make() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\src\\Setup.php:87, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  13. Codelight\\GDPR\\Container->resolve() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\vendor\\illuminate\\container\\Container.php:575, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  14. Codelight\\GDPR\\Container->build() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\vendor\\illuminate\\container\\Container.php:608, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  15. ReflectionClass->() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\vendor\\illuminate\\container\\Container.php:762, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  16. Codelight\\GDPR\\Components\\WordpressComments\\WordpressComments->__construct() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\vendor\\illuminate\\container\\Container.php:762, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.952018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  17. Codelight\\GDPR\\Components\\WordpressComments\\WordpressComments->setup() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\src\\Components\\WordpressComments\\WordpressComments.php:17, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.952018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  18. Codelight\\GDPR\\Options\\Options->get() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\src\\Components\\WordpressComments\\WordpressComments.php:22, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.952018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  19. get_option() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\gdpr-framework\\src\\Options\\Options.php:25, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.952018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  20. QM_DB->get_row() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\option.php:98, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.952018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  21. QM_DB->query() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\wp-db.php:2413, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.952018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  22. QM_DB->query() D:\\Projects\\Websites\\bayer-machines\\web\\wp-content\\plugins\\query-monitor\\wp-content\\db.php:100, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.952018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  23. QM_DB->_do_query() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\wp-db.php:1813, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.952018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  24. QM_DB->get_caller() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\wp-db.php:1931, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:27.952018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP  25. wp_debug_backtrace_summary() D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\wp-db.php:3412, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/
[Sun Jul 15 11:03:30.567167 2018] [mpm_winnt:notice] [pid 29428:tid 356] AH00428: Parent: child process 29440 exited with status 255 -- Restarting.

Honestly, I am not sure that this is related since the line in functions.php is completely different:

$caller[] = "{$call['class']}{$call['type']}{$call['function']}";

in wp_debug_backtrace_summary() but I'm posting it here as it seems again as a memory leak.

[itowhid06]

Is it possible that a filepath is being passed as "​file://path/file.ext" ?
In that case the following code won't execute and we are back to square one!

if ( false === strpos( $path, '://' ) ) {
        return false;
}

[tristanleboss]

If the problem comes from the repeated call to stream_get_wrappers, why don't we cache the output of this function in a function static variable? I mean it's not supposed to change during the same request.

<?php
function test()
{
 static $stream_get_wrappers = null;

 if( is_null($stream_get_wrappers) )
 {
  $stream_get_wrappers = stream_get_wrappers();
 }
}

[pbiron]

Replying to itowhid06:

Is it possible that a filepath is being passed as "​file://path/file.ext" ?
In that case the following code won't execute and we are back to square one!

if ( false === strpos( $path, '://' ) ) {
        return false;
}

Good catch! Nothing in core does so, but there is always the possibility that plugins do.

I'll have to think about the cleanest way to check for that case.

[pbiron]

Replying to ddenev:

Unfortunately, I got another crash today. Here is the Apache error log:

Honestly, I am not sure that this is related since the line in functions.php is completely different:

$caller[] = "{$call['class']}{$call['type']}{$call['function']}";

in wp_debug_backtrace_summary() but I'm posting it here as it seems again as a memory leak.

I can't be sure either, but it doesn't appear to me to be related. Seems to have something to do with the gdpr-framework plugin.

And the memory allocation error in:

[Sun Jul 15 11:03:27.951018 2018] [php7:notice] [pid 29440:tid 852] [client 192.168.88.11:22468] PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 17179869232 bytes) in D:\\Projects\\Websites\\bayer-machines\\web\\wp-includes\\functions.php on line 5158, referer: https://bayer-machines.ddev/products/plasma-cutting-machines/

seems to be the result of QM calling wp_debug_backtrace_summary() to report on whatever error occurred in gdpr-framework.

[itowhid06]

I'm proposing a patch based on @pbiron 's one. I've added two things. Firstly, normalizing the path, then added checking for if the filepath contains '​file://'

[pento]

Thanks for the suggestion, @itowhid06. In this case, we don't need to add a special check. file:// is still a stream, it's just a local stream, same as rar://, for example. if a path starting with file:// is sent to wp_is_stream(), it should return true.

The discussion in #43054 makes it pretty clear that this is a PHP memory corruption issue: a non-string value is somehow being returned by stream_get_wrappers(), which has two possible effects:

• The random data is small when interpreted as a string. (ie, reading it as string quickly encounters a NULL byte, indicating the end of the string.) This was fixed in #43054.
• The random data is huge when interpreted as a string. This is the issue that we're seeing here.

There are two ways of tackling this second issue:

• As in 44532.1.diff​, bailing if the path isn't a stream. This isn't perfect: it's still possible to trigger the PHP bug, but it does significantly reduce the chances of the bug being encountered. For many WordPress sites (those that don't have plugins that use streams), it reduces the chance to zero.

• Parse each wrapper name. As @dd32 mentioned on #43054, there are strict rules about what characters a wrapper name can contain. If we see an invalid character, bail on that wrapper name, and move onto the next one: it's a safe bet that a pointer to random memory will contain characters that aren't valid in a wrapper name: this would solve the issue for approximately 100% of cases. (There's a non-zero chance the random memory chunk we're given could actually be interpreted as data, and that the path sent to wp_is_stream() happens to match that random memory. 😉)

I'm strongly inclined to go with option one. Option two is quite complex, its a performance drag for the vast majority of calls, and it'll hopefully be made unnecessary in a future PHP release. Option one is simple, understandable, and it provides a performance improvement!

Unless any of the folks testing 44532.1.diff​ are still seeing the problem, I'm fine with it being committed and backported to the 4.9 branch in time for 4.9.8 beta 1.

[pbiron]

I was going to comment on patch.diff in the morning, but since I'm still up...

That patch would not work. Specifically, calling wp_normalize_path() would be bad, since wp_normalize_path() calls wp_is_stream()!

[dontstealmyfish]

Replying to pento:

Thanks for the suggestion, @itowhid06. In this case, we don't need to add a special check. file:// is still a stream, it's just a local stream, same as rar://, for example. if a path starting with file:// is sent to wp_is_stream(), it should return true.

The discussion in #43054 makes it pretty clear that this is a PHP memory corruption issue: a non-string value is somehow being returned by stream_get_wrappers(), which has two possible effects:

• The random data is small when interpreted as a string. (ie, reading it as string quickly encounters a NULL byte, indicating the end of the string.) This was fixed in #43054.
• The random data is huge when interpreted as a string. This is the issue that we're seeing here.

There are two ways of tackling this second issue:

• As in 44532.1.diff​, bailing if the path isn't a stream. This isn't perfect: it's still possible to trigger the PHP bug, but it does significantly reduce the chances of the bug being encountered. For many WordPress sites (those that don't have plugins that use streams), it reduces the chance to zero.

• Parse each wrapper name. As @dd32 mentioned on #43054, there are strict rules about what characters a wrapper name can contain. If we see an invalid character, bail on that wrapper name, and move onto the next one: it's a safe bet that a pointer to random memory will contain characters that aren't valid in a wrapper name: this would solve the issue for approximately 100% of cases. (There's a non-zero chance the random memory chunk we're given could actually be interpreted as data, and that the path sent to wp_is_stream() happens to match that random memory. 😉)

I'm strongly inclined to go with option one. Option two is quite complex, its a performance drag for the vast majority of calls, and it'll hopefully be made unnecessary in a future PHP release. Option one is simple, understandable, and it provides a performance improvement!

Unless any of the folks testing 44532.1.diff​ are still seeing the problem, I'm fine with it being committed and backported to the 4.9 branch in time for 4.9.8 beta 1.

I have had no problems for days after implementing 44532.1 diff

[pento]

Thanks for confirming that, @dontstealmyfish! Let's commit and backport 44532.1.diff​.

[pento]

In 43466:

Streams: Return early from wp_is_stream() for paths that aren't streams.

Some versions of PHP appear to have a memory leak that is occasionally triggered by calling stream_get_wrappers(). In order to avoid calling this, we can return early from wp_is_stream() when $path doesn't contain ://.

Props pbiron, JPry, dontstealmyfish.
Fixes #44532.

[pento]

Reopened for backport.

[SergeyBiryukov]

In 43484:

Streams: Return early from wp_is_stream() for paths that aren't streams.

Some versions of PHP appear to have a memory leak that is occasionally triggered by calling stream_get_wrappers(). In order to avoid calling this, we can return early from wp_is_stream() when $path doesn't contain ://.

Props pbiron, JPry, dontstealmyfish.
Merges [43466] to the 4.9 branch.
Fixes #44532.

[SergeyBiryukov]

#44614 was marked as a duplicate.

[GregLone]

Replying to tristanleboss:

If the problem comes from the repeated call to stream_get_wrappers, why don't we cache the output of this function in a function static variable? I mean it's not supposed to change during the same request.

Agree. Can't it help?

[sebastienserre]

Hello @SergeyBiryukov
Sorry if my question seems "crazy" but why @timbowesohft isn't in the props list?
He pointed this bug here and finally will be patched.

[pento]

Replying to tristanleboss:

If the problem comes from the repeated call to stream_get_wrappers, why don't we cache the output of this function in a function static variable? I mean it's not supposed to change during the same request.

I don't think this would help a huge amount, and has the potential to introduce other weird behaviour, and potentially security issues. For example, say you were to cache the output of stream_get_wrappers() that included a corrupt wrapper name. If it were a shorter bit of memory that it was reading from, then wp_is_stream() could be called a bunch of times, and return correctly (assuming it wasn't a stream we were trying to use that was being checked in those calls: if it was, then the function would be returning that we're unable to read from a stream that we can read from).

However, the memory that the corrupt wrapper name is pointing at could be deallocated at any time, and then allocated to something else: now we have a lump of memory that could potentially even be used by something outside the PHP process, and we're reading from it. This will often cause the PHP process to be terminated (modern OSes protect against processes reading outside of their allocated memory), but otherwise may cause strange information exposure issues.

Hello @SergeyBiryukov Sorry if my question seems "crazy" but why @timbowesohft isn't in the props list? He pointed this bug here and finally will be patched.

Thanks for noticing that, @sebastienserre! That was my mistake, I should've included him on the props list. We'll make sure he's given props in the 4.9.8 release post. 🙂