Arm*_*vic 8 php apache crash sigbus
我注意到我的系统一直在制作这个崩溃报告.我不确定为什么,我对阿帕奇内心的了解有限.我不确定是什么导致了这个,因为服务器上没有任何特别的变化.任何帮助表示赞赏.我应该寻找和检查什么？可能是什么原因造成的？
Apport会:
ERROR: apport (pid 8618) Mon Jan 25 14:35:24 2016: called for pid 8384, signal 7, core limit 0
ERROR: apport (pid 8618) Mon Jan 25 14:35:24 2016: executable: /usr/sbin/apache2 (command line "/usr/sbin/apache2 -k start")
ERROR: apport (pid 8618) Mon Jan 25 14:35:24 2016: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment
ERROR: apport (pid 8618) Mon Jan 25 14:35:52 2016: wrote report /var/crash/_usr_sbin_apache2.0.crash
_usr_sbin_apache2.0.crashProblemType: 崩溃报告 - 对于stackoverflow来说很大
谢谢你的时间=)
x86/ARM 设备上的信号 7 涉及SIGBUS（请参阅：）man 7 signal，表示总线错误（内存访问错误）。
总线错误是由硬件引发的故障，通知操作系统 (OS) 某个进程正在尝试访问 CPU 无法物理寻址的内存：地址总线的地址无效，因此得名。在大多数架构的现代使用中，这些错误比分段错误要少得多，分段错误主要是由于内存访问违规而发生的：逻辑地址或权限中的问题。
可能是错误、Apache 模块有问题或硬件问题。
由于Apport在 中生成了崩溃/var/crash/，您可以检查崩溃文件以获取更多详细信息。您可以在文本编辑器中打开它，但核心转储文件以 base64 格式打包。
要解压它，请运行：
cd /var/crash
sudo apport-unpack /var/crash/_usr_sbin_apache2.0.crash _unpacked
请参阅：如何从 /var/crash 读取崩溃文件和调试程序崩溃。
然后运行gdb分析崩溃文件：
gdb $(cat _unpacked/ExecutablePath) _unpacked/CoreDump
然后输入：bt或bt full检查堆栈跟踪。
假设您的 Apache 二进制文件没有使用调试符号进行编译，那么它不会有太大帮助。但是，您可以确定崩溃发生的位置，例如某些 Apache/PHP 模块，例如：
Program terminated with signal X, ...
#0 0x00007f39a616e09a in ?? () from /usr/lib/apache2/modules/libphp5.so
还可以通过从命令滚动列表来检查您获得的帧数bt，如果帧数过多（例如超过 1000 个），则潜在的问题是代码应用程序中某处存在无限循环。
如果您的应用程序在 PHP 下运行，要使用 进行更高级的调试gdb，请参阅：如何在 gdb 中获取当前 PHP 函数名称？
就像上面的例子一样，libphp5.so模块是处理 PHP 的主要模块。
要找出它属于哪个包，请运行：
$ dpkg -S /usr/lib/apache2/modules/libphp5.so
libapache2-mod-php5: /usr/lib/apache2/modules/libphp5.so
然后考虑升级有问题的库/模块。
如果某些第 3 方模块崩溃，请考虑通过禁用它php5dismod，例如
$ sudo apachectl -M
Loaded Modules:
...
$ sudo a2dismod somemodule
$ php -m
$ sudo php5dismod somemodule # Optionally.
$ sudo apachectl configtest
Syntax OK
$ sudo service apache2 reload
* Reloading web server config apache2
然后，如果问题仍然存在，请尝试使用从命令行重现它php。如果可以的话，请使用 进行调试strace，例如
$ strace -f php myscript.php
...
gettimeofday({1560725354, 768601}, NULL) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)
然后检查 PHP 进程在崩溃之前所做的最新操作。要增加消息的大小，请使用-s 1500，要保存到日志文件中，请使用-o file.log。