php7 oauth illegal memory allocation

Question

Intro

While running inside a complex web application, a spawned php7 process tries to allocate illegal amount of memory (18446744069414584466 bytes) when using the oauth module. After fpm manager restart the error appears after 2-5 times this code being triggered:

$oauthClient = new \OAuth($consumerKey, $consumerSecret, OAUTH_SIG_METHOD_HMACSHA1, OAUTH_AUTH_TYPE_AUTHORIZATION);
$oauthClient->disableSSLChecks();
$oauthClient->setToken($token, $tokenSecret);
$oauthClient->fetch($callUrl, $strPostData, $method, $headers);

Error Message

*20 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Allowed memory size of 536870912 bytes exhausted (tried to allocate 18446744069414584466 bytes)

Description

The affected line mentioned in the error message is the fetch method of the oauth client:

$oauthClient->fetch($callUrl, $strPostData, $method, $headers);

I've tried to isolate the related code by executing it in a loop and watching the memory usage over time. The amount of the used and allocated memory seems to grow steady over time, but not as fast as expected (probably it's only the oauthClient caching responses)

Standalone

Code

<?php

$strPostData = '';
$method = 'GET';
$consumerKey = '<consumerKey>';
$consumerSecret = '<consumerSecret>';
$token = '<token>';
$tokenSecret = '<tokenSecret>';
$url = '<url>';

$headers = array('accept' => 'application/json');
$callUrl = $url;

if ($method === 'POST' || $method === 'PUT') {
    $headers['Content-Type'] = 'application/json';
}

$oauthClient = new \OAuth($consumerKey, $consumerSecret, OAUTH_SIG_METHOD_HMACSHA1, OAUTH_AUTH_TYPE_AUTHORIZATION);
$oauthClient->disableSSLChecks();
$oauthClient->setToken($token, $tokenSecret);

do {
        $oauthClient->fetch($callUrl, $strPostData, $method, $headers);
        $response = $oauthClient->getLastResponse();
        fwrite(STDOUT, 'Allocated Memory: '. memory_get_usage(false) . PHP_EOL);
        fwrite(STDOUT, 'Used Memory: '. memory_get_usage(true) . PHP_EOL);
} while (true);
?>

Output

Allocated Memory: 236920
Used Memory: 262144
...
Allocated Memory: 263168
Used Memory: 524288
...
Allocated Memory: 289504
Used Memory: 524288
...
Used Memory: 524288
Allocated Memory: 331888
...
Allocated Memory: 395976
Used Memory: 524288
...
Allocated Memory: 428600
Used Memory: 524288
...

Core & Module Versions

Core: 7.0.8-3+deb.sury.org~trusty+1
date: 7.0.8-3+deb.sury.org~trusty+1
libxml: 7.0.8-3+deb.sury.org~trusty+1
openssl: 7.0.8-3+deb.sury.org~trusty+1
pcre: 7.0.8-3+deb.sury.org~trusty+1
zlib: 7.0.8-3+deb.sury.org~trusty+1
filter: 7.0.8-3+deb.sury.org~trusty+1
hash: 1.0
pcntl: 7.0.8-3+deb.sury.org~trusty+1
Reflection: 7.0.8-3+deb.sury.org~trusty+1
SPL: 7.0.8-3+deb.sury.org~trusty+1
session: 7.0.8-3+deb.sury.org~trusty+1
standard: 7.0.8-3+deb.sury.org~trusty+1
mysqlnd: mysqlnd 5.0.12-dev - 20150407 - $Id: 241ae00989d1995ffcbbf63d579943635faf9972 $
PDO: 7.0.8-3+deb.sury.org~trusty+1
xml: 7.0.8-3+deb.sury.org~trusty+1
bcmath: 7.0.8-3+deb.sury.org~trusty+1
calendar: 7.0.8-3+deb.sury.org~trusty+1
ctype: 7.0.8-3+deb.sury.org~trusty+1
curl: 7.0.8-3+deb.sury.org~trusty+1
dom: 20031129
mbstring: 7.0.8-3+deb.sury.org~trusty+1
fileinfo: 1.0.5
ftp: 7.0.8-3+deb.sury.org~trusty+1
gd: 7.0.8-3+deb.sury.org~trusty+1
gettext: 7.0.8-3+deb.sury.org~trusty+1
iconv: 7.0.8-3+deb.sury.org~trusty+1
json: 1.4.0
exif: 1.4 $Id: 8bdc0c8f27c2c9dd1f7551f1f9fe3ab57a06a4b1 $
mysqli: 7.0.8-3+deb.sury.org~trusty+1
OAuth: 2.0.2
pdo_mysql: 7.0.8-3+deb.sury.org~trusty+1
pdo_sqlite: 7.0.8-3+deb.sury.org~trusty+1
Phar: 2.0.2
posix: 7.0.8-3+deb.sury.org~trusty+1
readline: 7.0.8-3+deb.sury.org~trusty+1
shmop: 7.0.8-3+deb.sury.org~trusty+1
SimpleXML: 7.0.8-3+deb.sury.org~trusty+1
soap: 7.0.8-3+deb.sury.org~trusty+1
sockets: 7.0.8-3+deb.sury.org~trusty+1
sqlite3: 0.7-dev
ssh2: 0.13-dev
sysvmsg: 7.0.8-3+deb.sury.org~trusty+1
sysvsem: 7.0.8-3+deb.sury.org~trusty+1
sysvshm: 7.0.8-3+deb.sury.org~trusty+1
tokenizer: 7.0.8-3+deb.sury.org~trusty+1
wddx: 7.0.8-3+deb.sury.org~trusty+1
xmlreader: 7.0.8-3+deb.sury.org~trusty+1
xmlwriter: 7.0.8-3+deb.sury.org~trusty+1
xsl: 7.0.8-3+deb.sury.org~trusty+1
zip: 1.13.3
Zend OPcache: 7.0.8-3+deb.sury.org~trusty+1

Answer 1

I encountered a similar issue and tracked it down to a problem with using the oauth extension with opcache enabled. There's actually a bug open for php for the exact situation I was experiencing - https://bugs.php.net/bug.php?id=73310. We found a potential workaround for this problem until it's fully resolved, blacklisting the files leveraging the oauth extension for opcache clears up the exception.

You can blacklist files for opcache using the opcache.blacklist-filename option - http://php.net/manual/en/opcache.configuration.php#ini.opcache.blacklist-filename.

• Add a txt file on your server with the full path of each file you would like to blacklist on its own line
• Open opcache.ini in edit mode (eg sudo vi /etc/php/7.0/mods-available/opcache.ini)
• Edit the opcache.blacklist-filename option to point to the txt file you created with the blacklisted files
• If you are using fpm, restart it

Answer 2

An alternative to @shlm answer is to disable opcache all together.

In my project the decrease in response time was minimal, so for me it didn't make any notable difference, if I blacklisted the file or disabled opcache.

I disabled it with the following line in a .htaccess file.

php_flag opcache.enable Off