Question

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

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

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).

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.

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.

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

Answer 1

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.

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.

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.