矮人错误:找不到 DIE [英] Dwarf Error: Cannot find DIE

问题描述

我在 XCode 4 的 C++ 项目中调试分段错误时遇到了很多麻烦.

I am having a lot of trouble debugging a segmentation fault in a C++ project in XCode 4.

当我使用LLVM 2.0"编译器选项构建并使用 -O3 优化时，我只会遇到段错误.据我了解，使用优化时调试选项有限，但这是我在打开 gdb 的 Xcode 中运行后得到的调试输出:

I only get a segfault when I built with the "LLVM 2.0" compiler option and use -O3 optimization. From what I understand, there are limited debugging options when one is using optimization, but here is the debug output I get after I run in Xcode with gdb turned on:

warning: Got an error handling event: "Dwarf Error: Cannot find DIE at 0x3be2 referenced from DIE at 0x11d [in module /Users/imran/Library/Developer/Xcode/DerivedData/cgo-hczcifktgscxjigfphieegbpxxsq/Build/Products/Debug/cgo]".
No memory available to program now: unsafe to call malloc

在那之后我无法让 gdb 给我任何有用的信息(比如跟踪)，但我不确定我是否真的知道如何正确使用它.当我尝试使用LLDB"调试器时，Xcode 会崩溃(自从我开始使用它以来，这一直是一个常见的主题).

I can't get gdb to give me any useful info after that (like a trace), but I'm not sure I really know how to use it properly. When I try to use the "LLDB" debugger Xcode just crashes (which has been a common theme since I started using it).

我的程序是确定性的，但是当我尝试用打印语句隔离问题时，行为会改变.例如，如果我添加 cout <<"hello"; 段错误在某一时刻消失了.其他打印语句会导致我的程序在其主循环的不同迭代中出现段错误.当然，当我输入足够多的打印语句来确定有问题的代码时，段错误似乎发生在一行之后但在下一行之前(即无处).

My program is deterministic, but when I try to isolate the problem with print statements the behavior will change. For example if I add cout << "hello"; at one point the segfault goes away. Other print statements cause my program to segfault in a different iteration of its main loop. And naturally when I put in enough print statements to supposedly pinpoint the offending code, the segfault seems to occur after one line but before the next (i.e. nowhere).

我正在使用指针和动态内存分配，这可能是问题的原因，但由于我无法缩小导致错误的代码块，我不知道在此处显示什么代码.

I am using pointers and dynamic memory allocation, which is likely the cause of the problem, but since I can't narrow down the block of code causing the error I don't know what code to show here.

我尝试使用 Instruments 中的泄漏"工具进行分析，但没有发现任何泄漏.

I tried profiling with the "Leaks" tool in Instruments, but it didn't find any leaks.

有什么建议吗?我对调试非常缺乏经验，所以任何事情都会有所帮助，真的.

Any advice? I am very inexperienced with debugging so anything would help, really.

已解决.给定某些输入，我的程序会尝试读取数组末尾的内容.

Solved. Given certain inputs, my program would try to read past the end of an array.

推荐答案

我认为没有足够的信息可以帮助您解决 DWARF 问题.我对那个工具链不够熟悉，不知道它有多强大.

I don't think there's enough information that I can help you with the DWARF issue. I am not familiar enough with that toolchain to know how robust it is.

但是，您的崩溃症状闻起来很像堆损坏.我不知道 OSX 默认使用什么分配器，但常见的优化将元数据存储在对象内联和/或通过空对象线程化空闲列表，这使得它们对堆上的缓冲区溢出非常敏感.两次释放对象或使用悬空指针(已释放但其空间现在可能被另一个分配使用的指针)也会导致看似不确定且难以跟踪的错误，因为堆的布局可能会在运行.打印语句也使用分配器，这意味着更改打印语句可以改变问题出现的时间和地点.

Your crashing symptoms however smell a lot like heap corruption. I don't know what allocator OSX uses by default, but common optimizations store metadata inline with objects and/or thread the freelist through empty objects, which makes them very sensitive to buffer overflows on the heap. Freeing an object twice or using a dangling pointer (a pointer that has been freed but whose space may now be in use by another allocation) can also cause seemingly nondeterministic and hard to track errors, since the layout of the heap is likely to change between runs. Print statements also use the allocator, which means changing the print statements can change when and where the problem will appear.

我的顾问(http://prisms.cs.umass.edu/emery/index.php?page=download-diehard).我相信它将在 OSX 上构建，您可以使用 LD_PRELOAD=/path/to/libdiehard.so 将其链接到您的程序中，以在运行时替换默认分配器.它的唯一目的是防止内存错误和堆损坏，因此如果您的应用程序确实使用它运行，那可能就是您需要查看的地方.

A tool that you may find helpful in determining if this is a heap problem or something unrelated is a heap replacement called DieHard by my advisor (http://prisms.cs.umass.edu/emery/index.php?page=download-diehard). I believe it will build on OSX, and you can link it into your program using LD_PRELOAD=/path/to/libdiehard.so to replace the default allocator at runtime. Its sole purpose is to resist memory errors and heap corruption, so if your application actually runs with it, that's probably where you need to look.

这篇关于矮人错误:找不到 DIE的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！