从 crond 启动时出现 PHP 分段错误
我有一个 php 脚本，每分钟从 cron 启动一次。
除了 24 小时内运行大约 10 次之外，它几乎总是运行没有任何问题。
当它失败时，我会遇到如下分段错误： bin/sh: line 1: 21815 Segmentation failure /usr/bin/myscript
“line 1:”后面的数字总是不同的。
我正在运行： PHP 5.2.6-1+lenny8 with Suhosin-Patch 0.9.6.2 (cli) (build: Mar 14 2010 08:14:04)
这是我的 PHP 版本有问题吗？有没有办法调试这个？
我有一种感觉，当服务器负载高时它会崩溃，但绝对没有证据证明这一点。
欢迎任何反馈！
I've a php script that's started each minute from cron.
It almost always runs without any problem, except for about 10 times within 24h.
The times it fails I get a segmentation fault like:
bin/sh: line 1: 21815 Segmentation fault /usr/bin/myscript
The number after "line 1:" is always different.
I'm running:
PHP 5.2.6-1+lenny8 with Suhosin-Patch 0.9.6.2 (cli) (built: Mar 14 2010 08:14:04)
Is this a problem with my version of PHP? Is there a way to debug this?
I have the feeling it crashes when the server load is high, but there's absolutely no prove for this.
Any feedback is welcome!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我相信脚本不可能导致分段错误，它一定来自较低级别，您可以尝试删除 Suhosin 补丁或降级 PHP 并再次重新运行脚本。
I believe there is no way that a script cause a segmentation fault, it must be coming from lower levels, you can try removing Suhosin patch or downgrading PHP and rerun the script again.
我认为您必须尝试自己确定原因；当然，您可以在不同版本和/或没有补丁的测试环境中尝试它。
您还可以进行调试构建（当然是在测试环境中）并启用核心转储并使用调试器来查看失败时它在做什么。
在大多数情况下，这会发现它，但也可能是某些东西严重破坏了运行时环境，在这种情况下，针对调试库运行可能是您唯一的机会。
如果您可以在测试环境中重现这种情况，就很容易找出原因。准备好使用调试器并逐步执行 C（或者是 C++？）代码。
I think you'll have to try to determine the cause of this yourself; of course you can try it in your test environment with different versions and/or without the patch.
And you can also do a debug build (in test environment, of course) and enable core dumps and get a debugger to see what it was doing when it failed.
In most cases this will spot it, but it may be that something is severely corrupting the runtime environment, in which case running against debug libraries may be your only chance.
If you can get it to happen reproducibly in a test environment, it's easy to identify the cause. Be prepared to use your debugger and step through the C (or is it C++?) code.