php7 oauth非法内存分配 [英] php7 oauth illegal memory allocation

查看:65
本文介绍了php7 oauth非法内存分配的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

简介

在复杂的Web应用程序中运行时,使用oauth模块时,生成的php7进程尝试分配非法的内存量(18446744069414584466字节).在fpm manager重新启动后,在触发此代码2-5次后,错误出现:

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

错误消息

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

说明

错误消息中提到的受影响的行是 oauth客户端 fetch 方法:

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

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

我试图通过循环执行相关代码并观察一段时间内的内存使用情况来隔离相关代码.使用和分配的内存量似乎会随着时间稳定增长,但并没有达到预期的速度(可能只是oauthClient缓存响应)

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)

独立

代码

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

输出

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

推荐答案

我遇到了类似的问题,并将其追溯到使用启用了opcache的oauth扩展的问题.实际上,针对我所遇到的确切情况,有一个针对PHP的错误正在打开- https://bugs. php.net/bug.php?id=73310 .我们找到了解决该问题的潜在解决方案,直到完全解决该问题为止,利用oauth扩展将文件列入opcache的黑名单可以清除该异常.

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.

您可以使用opcache.blacklist-filename选项将操作缓存文件列入黑名单- http://php.net/manual/en/opcache.configuration.php#ini.opcache.blacklist-filename .

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

  • 在服务器上添加一个txt文件,其中要在其行上将每个要列入黑名单的文件的完整路径
  • 以编辑模式(例如sudo vi/etc/php/7.0/mods-available/opcache.ini)打开opcache.ini
  • 编辑opcache.blacklist-filename选项以指向使用黑名单文件创建的txt文件
  • 如果您使用的是fpm,请重新启动它

这篇关于php7 oauth非法内存分配的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆