0

I'm trying to use C++11 (with Clang and libc++ on OS X) for a program, but whenever I debug with gdb and try to inspect standard containers, gdb segfaults. Here's a minimal example:

file.cpp:

#include <iostream>
#include <string>

int main(int argc, char* argv[])
{
    std::string str = "Hello world";

    std::cout << str << std::endl; // Breakpoint here
}

If I compile for C++11 using the following:

$ c++ --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
$
$ c++ -ggdb -std=c++11 -stdlib=libc++ -Wall -pedantic -O0 -c file.cpp
$ c++ -ggdb -std=c++11 -stdlib=libc++ -Wall -pedantic -O0 file.o -o program

And then debug as follows, it crashes when I try to p str.size():

$ gdb program
GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb  6 22:51:23 UTC 2013)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ... done

(gdb) br file.cpp:8
Breakpoint 1 at 0x100000d80: file file.cpp, line 8.
(gdb) run
Starting program: /Users/mjbshaw/School/cs6640/2/program 
Reading symbols for shared libraries ++............................. done

Breakpoint 1, main (argc=1, argv=0x7fff5fbffab0) at file.cpp:8
8       std::cout << str << std::endl; // Breakpoint here
(gdb) p str.size()

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
std::__1::operator<< <char, std::__1::char_traits<char>, std::__1::allocator<char> > (__os=@0x7fff5fc3d628, __str=@0x1) at string:1243
1243    
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__is_long() const) will be abandoned.

If I don't run this in gdb, I get no crash and it works fine (but I need gdb to debug my program). Also, if I remove -std=c++11 -stdlib=libc++ from the compiling options, then it works fine (even in gdb), but I need C++11 for my program.

Are there some known issues with gdb and C++11 (specifically libc++)? I know libc++ and libstdc++ can cause issues if used together, but I'm not trying to use them together (at least not consciously; all I want to use is libc++). Am I specifying some compilation options wrong? Is there a way to properly compile for C++11 on OS X and still be able to debug properly?

Cornstalks
  • 37,137
  • 18
  • 79
  • 144
  • 3
    gdb 6.3 is a fossil. Upgrade to the latest version. – n. m. could be an AI Sep 23 '13 at 15:11
  • @n.m. if you post as answer, I'll accept. I just updated to 7.6.1 and it's working now. Curse Apple for shipping old GDB. – Cornstalks Sep 23 '13 at 15:18
  • And for those wondering how I updated GDB, I used [the answer from here](http://stackoverflow.com/questions/8336433/gdb-on-macosx-lion) and did: `brew install https://raw.github.com/Homebrew/homebrew-dupes/master/gdb.rb`. Note that you'll want to [codesign the new gdb](http://sourceware.org/gdb/wiki/BuildingOnDarwin) to debug with it as non-root. – Cornstalks Sep 23 '13 at 15:21
  • 2
    With Clang/libc++ on OS X, it might be better to use [lldb](http://lldb.llvm.org/lldb-gdb.html). – Brett Hale Sep 23 '13 at 21:23
  • Note that if you run gdb through Xcode rather than through the command line, DO NOT try to upgrade gdb as described in the above comments. I just wasted a bunch of time trying that only to find the gdb Xcode uses is heavily modified to work only with Xcode. The best you can do is upgrade to the latest gdb shipped with Xcode 4.6.3 (which actually works on Mavericks in Xcode 3 whereas Xcode 3's shipped gdb crashes on Mavericks). Xcode 5 and later ship only with lldb. – Winter Dragoness Dec 09 '14 at 19:19

1 Answers1

1

GDB 6.3 is almost nine years old. That's just about eternity in Internet years. The product has improved greatly since then. Updating to the last stable release is a must for every developer.

n. m. could be an AI
  • 112,515
  • 14
  • 128
  • 243