追踪分段错误 11 到大型 PHP 代码库答案

【问题标题】：Tracking down a segmentation fault 11 to large PHP code base追踪分段错误 11 到大型 PHP 代码库
【发布时间】：2012-10-09 03:27:22
【问题描述】：

好的，所以有一个相当庞大的内部系统。我们有一位友善的主人，如果出现问题，他通常会与我们一起工作，以保持一切正常，或者至少为我们指明正确的方向。

不久前，我们不得不获取代码的副本并将其托管在由 Rackspace 托管的客户端外部专用服务器上。考虑到几个月来一切都运行良好，突然间服务器不断抛出嘶嘶声和分段错误，例如

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

尽管没有更改任何代码，但主办方表示这可能是 PHP 问题，开发人员（我们）将不得不对其进行调查。我什至没有看到问题，只是在某些时候 apache 日志旋转（深夜）这会导致它倒下。

我让它们启用核心转储，我拥有一堆它们，Fixing Apache Segmentation Faults Caused by PHP，但 rackspace 似乎已经将所有 php 和 apache 源目录移动到天知道在哪里，我在任何地方都找不到 .gdbinit在使用'find'的服务器上，我能从gdb中得到的只是

Program terminated with signal 11, Segmentation fault.
#0  0x00002b8d6fc36c60 in ?? ()

...如果尝试过，它的帮助不会少！！！

关于在我的代码中从哪里开始追踪这个假定的问题有什么想法吗？

【问题讨论】：

我们遇到了同样的问题。 Apache 在轮换日志时尝试优雅地重新启动。它并不总是干净利落地回来。我已经安装了 cronolog，这样 Apache 就不必为了轮换日志而关闭。这可能是一个 PHP 问题，但它在 Apache 重新启动之前一直有效......所以......
看看这个答案：stackoverflow.com/questions/7745578/…
@tubaguy50035 ...你的意思是它的机架空间问题？
分段错误是 PHP 内部错误，有时是 Apache 错误。但是如果没有适当的日志，即使填写错误报告也是无用的
乌丹是对的。如果不记录阳光下的一切，就无法知道发生了什么。听起来您的问题与我所经历的非常相似。我认为不值得你花时间调试。

标签： php apache segmentation-fault

【解决方案1】：

您可以从将 PID 添加到 apache 日志开始，然后查看哪个死了……您将看到它是否至少是相同的请求。

也许您可以在崩溃开始之前看到更新的内容，并且如果某些模块已更新并且没有它们就无法生存，也许您可以回滚到以前的配置。

【讨论】：

嗯，我注意到他们在我们开始注意到问题之前大约一周升级了 PHP，我向他们指出了这一点！但他们只是回应说'导致段错误的 PHP 升级将比事后一周更直接。不幸的是，除非您有可以复制问题的测试用例，否则无法确认。 :( 叹息

【解决方案2】：

如果您知道如何使用 GDB 调试应用程序内核，here 是源 RPM 和 RPM。

我还建议您在应用程序核心上运行“字符串”。这不会给你确切的问题，但在许多情况下，它会提供一些有用的东西。

HTH

【讨论】：