使用 g++ 编译时出现非法指令
我有一个问题，在 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?)
不知道为什么回溯中没有 main 。这 ？？似乎是我的 linux 库的一部分，其中没有调试符号。
我现在的问题是：程序有什么问题？ lapack库是否被错误编译（我几天前编译过）？或者还有其他错误吗？
我确实没有汇编程序或类似的东西。只有C++。
谢谢 基督教
I have the problem that a C++ program running under linux, compiled with g++ raises after some time a illegal instruction exception and I get a core dump. When I do a backtrace using gdb I get
(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?)
I do not know why there is no main in the backtrace. The ?? seems to be part of my linux libraries which have no debugging symbols in.
My question is now: What is the problem with the program? Is the library lapack falsely compiled (I copiled it some days ago)? Or is there any other error?
I did definitfly no assembler or similar things. Only C++.
Thanks
Christian
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这通常意味着堆栈被破坏。特别是 0x00000001 的值，它不太可能是有效的堆栈地址，所以我想说你溢出了堆栈分配的缓冲区并覆盖了返回地址。
That usually means smashed stack. Especially the value of 0x00000001, which is pretty damn unlikely to be a valid stack address, so I'd say you overflowed a stack-allocated buffer and overwrote the return address.
DeadMG 所说的，加上：
非法指令通常是编译为使用运行机器上不可用的 CPU 指令的二进制文件的结果。例如，如果您进行类似编译
，然后在不支持 SSE4 指令集的 Intel Atom CPU 上运行该程序，则可能会发生这种情况。崩溃不一定会发生，例如，不太可能
生成 while 原因 SSE4 指令。当然，对于不太可能的代码路径也是如此，现在可能不会导致崩溃，但将来会导致崩溃。
要查找堆栈粉碎代码，您可以考虑使用 cppcheck 或类似的 LINT, Valgrind，以分而治之的方式进行良好的老式 printf/cout 调试，或者使用检查了STL的实现。
What DeadMG said, plus:
Illegal instructions are usually the results of binaries that are compiled to use CPU instructions not available on the running machine. This can happen for example if you compile like
and then run the thing on an Intel Atom CPU, which does not support the SSE4 instruction set. The crash does not necessarily happen, e.g. it is unlikely that
while cause SSE4 instructions be generated. Same of course for unprobable codepaths, which may cause no crash now, but in the future.
To find the stack smashing code, you might consider a LINT like cppcheck or similar, Valgrind, good old printf/cout debugging in a divide and conquer manner, or using a checked STL implementation.
正如其他人所说，你可能已经搞砸了你的堆栈。
最常见的原因是：
找到原因的神奇方法是：（
只需在您通常启动的命令前面添加“valgrind”如果还没有安装 valgrind，则必须在您的发行版上有一个包，因为它是一种广泛使用的工具。）
然后 valgrind 将在运行时检查您的程序（稍微减慢速度）并立即报告您因为写入发生在不应该发生的地方（例如，在堆栈上）
as the other have said, you probably have screwed your stack.
The most common causes are :
The magic way to find the cause is :
(just add "valgrind" in front of the command you usually launch. Install valgrind if not already here, must have a packet for it on your distro since it is a widely used tool.)
Then valgrind will inspect your program while it run (slowing it a bit) and report you immediatly as soon as a write happen where it should not (for example, on the stack)