php7 oauth allocazione di memoria illegale

Question

Introduzione

Mentre esecuzione all'interno di un'applicazione web complesso, un processo php7 generato tenta di allocare quantità illegale di memoria (18446744069414584466 byte) quando si utilizza il modulo oauth. Dopo direttore FPM riavviare l'errore compare dopo 2-5 volte di questo codice viene attivato:

$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); 

messaggio di errore

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

Descrizione

La linea interessata menzionato nel messaggio di errore è il metodo fetch del client oauth:

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

Ho provato a isolare il codice correlato eseguendolo in un ciclo e osservando l'utilizzo della memoria nel tempo. La quantità di memoria utilizzata e allocata sembra crescere costante nel tempo, ma non così rapidamente come previsto (probabilmente è solo le risposte oauthClient caching)

Standalone

Codice

<?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); 
?> 

uscita

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 
... 

Nucleo & versioni del modulo

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

ho incontrato un problema simile e monitorati in giù ad un problema con l'utilizzo dell'estensione OAuth con opcache abilitato. In realtà c'è un bug aperto per php per l'esatta situazione che stavo vivendo - https://bugs.php.net/bug.php?id=73310. Abbiamo trovato una soluzione alternativa per questo problema finché non è stato completamente risolto, inserendo nella blacklist i file che sfruttano l'estensione oauth per opcache si cancella l'eccezione.

È possibile mettere in blacklist i file per opcache utilizzando l'opzione opcache.blacklist-filename - http://php.net/manual/en/opcache.configuration.php#ini.opcache.blacklist-filename.

• aggiungere un file txt sul vostro server con il percorso completo di ogni file che si desidera mettere in blacklist sulla propria riga
• aperto opcache.ini in modalità di modifica (ad es sudo vi /etc/php/7.0/ mods-available/opcache.ini)
• Modificare l'opcache.opzione lista nera-filename per puntare al file txt si è creato con i file di lista nera
• Se si utilizza FPM, riavviarlo

Answer 2

Dal nulla, questo ha funzionato per me come fascino

$this->oauth->fetch($endpoint, [], 'GET', ['Accept' => 'application/json']); 

diventa

$this->oauth->fetch($endpoint, ['fix'], 'GET', ['Accept' => 'application/json']); 

Sì, basta compilare il secondo parametro e non lasciarlo vuoto.