Question

我遇到的问题是，在linux下运行的C ++程序，用g ++编译后会在一段时间后引发非法指令异常并且我得到核心转储。当我使用gdb进行回溯时，我得到了

(gdb) bt
#0  0x005e18cf in ATL_dpotrfL () from /usr/lib/liblapack.so.3gf
#1  0x00000001 in ?? ()
#2  0xb786f2e8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

我不知道为什么回溯中没有主要内容。 ?? ??似乎是我的linux库的一部分，它没有调试符号。

我现在的问题是：该计划有什么问题？图书馆lapack是否被错误编译（我几天前复制了它）？或者还有其他错误吗？

我做了definitfly没有汇编或类似的东西。只有C ++。

由于基督教

Answer 1

这通常意味着粉碎堆栈。特别是0x00000001的值，这很可能不是一个有效的堆栈地址，所以我要说你溢出了堆栈分配的缓冲区并覆盖了返回地址。

Answer 2

DeadMG说了什么，加上：

非法指令通常是编译为使用正在运行的计算机上不可用的CPU指令的二进制文件的结果。例如，如果您编译为

，就会发生这种情况

g++ -msse4 ...

然后在Intel Atom CPU上运行该东西，该CPU不支持SSE4指令集。崩溃不一定发生，例如

不太可能

int main () {}

同时生成SSE4指令。当然，对于不可能的代码路径也是如此，现在可能不会导致崩溃，但将来也不会崩溃。

要查找堆栈粉碎代码，您可以考虑使用类似cppcheck or similar，Valgrind的LINT，以分而治之的方式进行良好的旧版printf / cout调试，或者使用已检查的STL实现。

Answer 3

正如对方所说，你可能搞砸了你的筹码。

最常见的原因是：

写一个坏指针（已删除）
在尖头空间之外写作
在堆栈上声明巨大的本地数据

找到原因的神奇方法是：

valgrind  your_program  [args]

（只需在你通常启动的命令前添加“valgrind”。如果还没有在这里安装valgrind，必须在你的发行版上有一个数据包，因为它是一个广泛使用的工具。）

然后valgrind将在程序运行时检查你的程序（稍微放慢一下），并在写入发生时尽快报告你（例如，在堆栈上）

使用g ++编译时的非法指令

3 个答案: