Linux：关于信号 4 的核心转储
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/8556447/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Linux: Core dump about signal 4
提问by wande
On linux platform, my application program got core dump occasionally due to a signal 4. And I find that signal 4 means Illegal Instruction. So I have one question: How to got Illegal Instruction and what might cause signal 4 core dump.
在linux平台上，由于信号4，我的应用程序偶尔会出现core dump。我发现信号4表示非法指令。所以我有一个问题：如何获得非法指令以及可能导致信号 4 核心转储的原因。
回答by sarnold
You might have compiled code for a different processor model or you might have installed code intended for a different processor model. There are a huge variety of impressive SIMDinstructions in modern CPUs to speed up compute-intensive tasks (MMX, SSE, SSE2, SSSE3, SSE4.1, SSE4.2, 3dNOW! (and its derivatives)), instructions for faster system calls, instructions for faster lock handling (popcnt), instructions for computing rounds of AES, etc.
您可能已经为不同的处理器模型编译了代码，或者您可能已经安装了用于不同处理器模型的代码。现代 CPU中有大量令人印象深刻的SIMD指令来加速计算密集型任务（MMX、SSE、SSE2、SSSE3、SSE4.1、SSE4.2、3dNOW！（及其衍生物）），以及用于更快系统调用的指令、更快的锁处理指令（popcnt）、计算 AES 轮次的指令等。
Perhaps your code was compiled assuming some of these instructions were available, but your CPU does not support them.
也许您的代码是在假设其中一些指令可用的情况下编译的，但您的 CPU 不支持它们。
Another possibility is bad memory or corrupted data on your hard drive. memtest86can help you find bad memory, and you can use debsumsor rpm -qVor similar package manager commands to check if your programs still match the checksums they had when they were first installed.
另一种可能性是硬盘驱动器上的内存损坏或数据损坏。memtest86可以帮助您找到坏内存，您可以使用debsums或rpm -qV或类似的包管理器命令来检查您的程序是否仍然与它们首次安装时的校验和匹配。
回答by Basile Starynkevitch
A more frequent possibility is the usage of an uninitialized or corrupted function pointer (or vtable in C++).
更常见的可能性是使用未初始化或损坏的函数指针（或 C++ 中的 vtable）。
If your C code calls a corrupted function pointer, that address may lead anywhere, including inside some data, which, when the processor tries to execute it, will give you a SIGILL signal.
如果您的 C 代码调用损坏的函数指针，该地址可能指向任何地方，包括某些数据内部，当处理器尝试执行它时，会给您一个 SIGILL 信号。
It could also happen with label as valuesand computed goto *x;(a commonly used GCC extension to C), if jumping to a bad address.
如果跳转到错误地址，标签作为值并计算goto *x;（C 的常用 GCC 扩展）也可能发生这种情况。
It could even happen if you corrupt your call stack badly enough to overwrite the return address.
如果您严重破坏调用堆栈以覆盖返回地址，它甚至可能发生。
Very probably, using your gdbdebugger (or perhaps also valgrind) should help you.
很可能，使用您的gdb调试器（或者也可能valgrind）应该对您有所帮助。
My advice is to always initialize pointers (e.g. to NULL), including function pointers. IIRC, if you call the NULL function pointer, you get a SIGSEGV.
我的建议是始终初始化指针（例如指向 NULL），包括函数指针。IIRC，如果你调用 NULL 函数指针，你会得到一个 SIGSEGV。
