当使用超过128M的PHP分段错误

我有一个SugarCRM的安装。 记忆力很重,这是一个需要处理的问题。 与此同时,任何尝试使用超过128M内存的页面都会导致Apache(mod_php)进程因分段错误而停止运行:

[notice] child pid 6852 exit signal Segmentation fault (11) 

如果我将PHP内存限制设置为128M,那么我永远不会收到信号11; 我只是得到正常的PHP错误,告诉我它不能分配任何更多的内存。 如果我将PHP内存限制设置为大于128M(甚至稍微高于此值),则任何进入该内存的进程都会导致分段错误和用户的白屏/断开连接。

我在Atomic资源库的CentOS 6.2服务器上使用PHP 5.3.21。 这是一个生产服务器,所以不存在编译器,所以重新编译Apache进程来做核心转储是不可能的。

我们已经安装了APC 3.1.13,并且需要一些站点。 这是(我相信)我的SugarCRM网站禁用。

我不确定需要其他哪些详细信息来诊断此问题? 我希望能看到一些明显的东西,如果这里有人遇到类似的东西。 如果内存使用率超过了128M,会导致崩溃的是什么?

编辑:

情节变厚了。 运行此testing脚本,将256M设置为memory_limit,直到PHP进程耗尽大约256M的内存为止。 它不会导致分段错误; 它运行并正常终止:

 <?php phpinfo(); $array = array(); while (true) { $array[] = str_pad('', 1024*512, '0'); echo " " . memory_get_usage(); } 

所以我们可以看到SugarCRM(一个普通的PHP / MySQL应用程序)导致了分段错误,但是只有当memory_limit被设置为大于128MBytes并且达到了超过128MByte阈值的页面。 这将是非常棘手的缩小范围。 无论是由一行特定的PHP代码或应用程序中的构造引起的,还是由应用程序碰巧发生的整个系列事件造成的结果(例如,执行触发垃圾收集器开始整理的东西,或者取消设置有数据库连接打开,或者像我可以想象的各种各样的事情)来触发PHP的错误,目前还不清楚。

如果事实certificate这是一个服务器问题,也许是编程方法,我不会感到惊讶。

编辑2:

我现在可以轻松地重现分段错误:

 <?php function test1() { static $instance = 0; $instance += 1; echo " $instance "; test1(); } test1(); 

可能会出现seg故障,做这种事情。 就个人而言,我希望它会被PHP处理好一点,但也许这是PHP的课程? 只要memory_limit设置为128M,那么它似乎处理得很好。 当我把它设置为256M,然后它seg故障。

通过逐步执行应用程序,似乎进入一个recursion循环,因为写入它的初始caching文件(SugarCRM做了很多caching)。 这很难遵循,但我怀疑这是由于缺lesserror handling引起的 – 它写入一个文件然后只是希望文件在那里,而不检查fopen()的结果。 我们正在运行SELinux,现在我想知道这是否会影响到它 – 其他应用程序中肯定有这样的情况,PHP的is_writeable()表示“很好,你可以在这里写一个文件”,但是这样做的话,SELinux会踢进一个说,“你没有办法在这里写这个文件”。 SugarCRM检查第一个问题,然后不总是检查它是否真的成功。

所以 – 我希望这可以被认为是一个编程问题呢? 这对服务器和PHP来说仍然是一个问题,在我看来,它们并不是很好,但是在SugarCRM中有足够的错误修复应该可以解决这个问题。

  • 如何在运行Coldfusion / MySql的Apache服务器(localhost)上提供php文件?
  • 我怎样才能从CLI运行一个PHP脚本,而无需预先“PHP”?
  • Nginx:限制访问所有,但PHP
  • PHP升级总是破坏会话文件夹的权限
  • HHVM随机停止运行
  • 我们如何才能dynamic地限制每个用户的nginx上传/下载速度?
  • 2 Solutions collect form web for “当使用超过128M的PHP分段错误”

    这跟我已经很接近了,也许就我现在要说的是:

    1. SugarCRM不会错误地检查其文件写入命令是否正确,所以有时不知道文件还没有被写入。

    2. SugarCRM在首次运行时构build运行时文件时会写入大量的caching文件。

    3. 构build这些caching文件时,某些不正确的权限会导致某些文件无法正确写入。

    4. 丢失的文件把SugarCRM放入一个无尽的recursion循环,caching写入方法recursion地调用自己。

    5. 由于PHP的memory_limit设置为128M以上,而不是报告进程内存不足,所以会出现分段错误。 在128M以下和PHP进程被更干净地杀死。 我只能假设这是一个PHP错误,或一个插件(而不是APC)中的错误。 128M的价值来自哪里,我不知道。

    我通过重新安装SugarCRM来修复它,将所有文件和目录设置为777,然后运行。 权限现在需要恢复,直到我find失败的地方。 到SugarCRM(社区版)的门票将是有用的,如同一张票(虽然我希望我将无法给他们核心转储,他们不可避免地要求,这可能是一个死胡同)。

    感谢您的build议。 我希望这对其他人有用。

    摆脱APC,并replace它的替代品之一eAccelerator或XCache。 在我的生产环境中,这是类似于这种神秘的崩溃的原因,所有这些都在APC一走了之后就消失了。

    服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器.